On 13/11/14 13:37, Karanbir Singh wrote: > On 11/13/2014 01:19 PM, Akemi Yagi wrote: >> On Thu, Nov 13, 2014 at 4:50 AM, Marcelo Barbosa >> <firemanxbr at fedoraproject.org> wrote: >>> Hi everybody, >>> >>> I have some servers running CentOS 6.5 with network driver >>> "via_velocity", but in new CentOS release (7.0.1406) this driver not >>> present, more informations bellow: >>> >>> # modprobe via_velocity >>> modprobe: FATAL: Module via_velocity not found. >> >>> Sugestions ? >> >> via_velocity is one of the many drivers removed from RHEL/CentOS 7. I >> suggest you ask ELRepo to provide a kmod package for the driver. >> Another option is to ask CentOS to enable the driver in the centosplus >> kernel. Either way, you can use the respective project's bug tracker. > > is it just a case of turning it on in the kernel config ? might be worth > doing in the plus kernel, if we can test it. > > Karanbir, Yes, a lot of older ethernet drivers were turned off in the rhel7 kernel config, so these can be turned back on to active / build them. However, there is one potential issue in doing that - RH will not be maintaining the code for those drivers (i.e, will not be backporting security patches for those drivers into their kernel source) so you are activating a driver based on code that isn't going to be maintained going forward. Building the module independently from the 3.10.x branch has the advantage that code is under long-term support so the code base is maintained for now and the driver may be easily updated as and when required. You could certainly backport patches as necessary into your CentOS-Plus kernel as and when they appear upstream at kernel.org for drivers you add that are unmaintained by Red Hat if that's what you want to do. Maintaining your own kernel backports / updates also has the potential to put CentOS-Plus kernel releases out of sync with upstream RHEL kernel releases when a critical security issue is identified that affects the CentOS-Plus kernel but does not affect the RHEL kernel, due to an additional driver you have activated. Thus IMHO it's easier to maintain such drivers out of kernel as independent kmod packages. It's really just a question of how (or if) you want to manage all this. PS - I appreciate you are no doubt fully aware of all of this, so I'm more putting it out there to hopefully generate some thoughtful discussion on the issue :-)