Is it beyond reason to request certain older drivers be enabled in the i686 kernel for CentOS 7 to help support the older hardware that you might find in 32 bit machines? I have an old gateway laptop that I'm trying it out on and it needs the b43 driver enabled.
Thanks,
Peter
On Sat, Oct 3, 2015 at 8:19 AM, Peter peter@pajamian.dhs.org wrote:
Is it beyond reason to request certain older drivers be enabled in the i686 kernel for CentOS 7 to help support the older hardware that you might find in 32 bit machines? I have an old gateway laptop that I'm trying it out on and it needs the b43 driver enabled.
Is there any reason you can't grab the SRPM and, for the short term, build it yourself using "mock" and the new testable i386 repo? Or, for the short term, grab a USB/wifi device with an old, standard chipset and just use that until this gets worked out? I've done both in the past for older operating systems.
On 10/04/2015 03:37 AM, Nico Kadel-Garcia wrote:
On Sat, Oct 3, 2015 at 8:19 AM, Peter peter@pajamian.dhs.org wrote:
Is it beyond reason to request certain older drivers be enabled in the i686 kernel for CentOS 7 to help support the older hardware that you might find in 32 bit machines? I have an old gateway laptop that I'm trying it out on and it needs the b43 driver enabled.
Is there any reason you can't grab the SRPM and, for the short term, build it yourself using "mock" and the new testable i386 repo? Or, for the short term, grab a USB/wifi device with an old, standard chipset and just use that until this gets worked out? I've done both in the past for older operating systems.
That's exactly what I'm doing now, but I'm putting the request in as well as I'd like to not have to rebuild the kernel myself each time a new one comes out, I'd much rather the driver is enabled in the stock CentOS kernel if possible.
Peter
On Sat, Oct 3, 2015 at 10:40 AM, Peter peter@pajamian.dhs.org wrote:
On 10/04/2015 03:37 AM, Nico Kadel-Garcia wrote:
On Sat, Oct 3, 2015 at 8:19 AM, Peter peter@pajamian.dhs.org wrote:
Is it beyond reason to request certain older drivers be enabled in the i686 kernel for CentOS 7 to help support the older hardware that you might find in 32 bit machines? I have an old gateway laptop that I'm trying it out on and it needs the b43 driver enabled.
Is there any reason you can't grab the SRPM and, for the short term, build it yourself using "mock" and the new testable i386 repo? Or, for the short term, grab a USB/wifi device with an old, standard chipset and just use that until this gets worked out? I've done both in the past for older operating systems.
That's exactly what I'm doing now, but I'm putting the request in as well as I'd like to not have to rebuild the kernel myself each time a new one comes out, I'd much rather the driver is enabled in the stock CentOS kernel if possible.
Cool! I'm glad it's working! That means it's actually tested, at least in one environment! That's sometimes the hardest part of getting a change made, is actually testing that it works! That means you've got the modified SRPM and could send a patch to go with the request?
On 10/04/2015 04:00 AM, Nico Kadel-Garcia wrote:
That's exactly what I'm doing now, but I'm putting the request in as well as I'd like to not have to rebuild the kernel myself each time a new one comes out, I'd much rather the driver is enabled in the stock CentOS kernel if possible.
Cool! I'm glad it's working! That means it's actually tested, at least in one environment! That's sometimes the hardest part of getting a change made, is actually testing that it works! That means you've got the modified SRPM and could send a patch to go with the request?
No, I'm working on it now, but being that I'm about to head to bed I'll probably do it tomorrow. It should just be a one line change to the .config file, though.
Peter
On 03/10/15 15:40, Peter wrote:
On 10/04/2015 03:37 AM, Nico Kadel-Garcia wrote:
On Sat, Oct 3, 2015 at 8:19 AM, Peter peter@pajamian.dhs.org wrote:
Is it beyond reason to request certain older drivers be enabled in the i686 kernel for CentOS 7 to help support the older hardware that you might find in 32 bit machines? I have an old gateway laptop that I'm trying it out on and it needs the b43 driver enabled.
Is there any reason you can't grab the SRPM and, for the short term, build it yourself using "mock" and the new testable i386 repo? Or, for the short term, grab a USB/wifi device with an old, standard chipset and just use that until this gets worked out? I've done both in the past for older operating systems.
That's exactly what I'm doing now, but I'm putting the request in as well as I'd like to not have to rebuild the kernel myself each time a new one comes out, I'd much rather the driver is enabled in the stock CentOS kernel if possible.
You don't need to rebuild the whole kernel just for one driver - just build the driver out of tree.
On 03/10/15 13:19, Peter wrote:
Is it beyond reason to request certain older drivers be enabled in the i686 kernel for CentOS 7 to help support the older hardware that you might find in 32 bit machines? I have an old gateway laptop that I'm trying it out on and it needs the b43 driver enabled.
Thanks,
Peter
The main issue here is one of security.
There is no responsibility on Red Hat to maintain drivers disabled in the RHEL7 kernel, so if CentOS enables drivers for a 32-bit kernel build that are disabled by default in the RHEL kernel, then CentOS would need to take responsibility/ownership for maintaining those drivers within the CentOS kernel, backporting security fixes as necessary.
That is a very different proposition than just rebuilding upstream sources, requiring a very different skill set and resources.
Further, down the line you will most likely find that the driver won't compile when enabled. For example, the wireless stack has been updated in the RHEL7.2beta kernel from kernel-4.1-rc6, yet the b43 driver in the kernel source will still be from the original 3.10.0 branch. It's unlikely to compile and will probably need backporting from 4.1.
Your best bet is probably to backport the driver yourself and build it out of tree - a lot simpler than building a whole kernel just for one driver.
On 10/04/2015 10:57 AM, Ned Slider wrote:
There is no responsibility on Red Hat to maintain drivers disabled in the RHEL7 kernel, so if CentOS enables drivers for a 32-bit kernel build that are disabled by default in the RHEL kernel, then CentOS would need to take responsibility/ownership for maintaining those drivers within the CentOS kernel, backporting security fixes as necessary.
That is a very different proposition than just rebuilding upstream sources, requiring a very different skill set and resources.
Further, down the line you will most likely find that the driver won't compile when enabled. For example, the wireless stack has been updated in the RHEL7.2beta kernel from kernel-4.1-rc6, yet the b43 driver in the kernel source will still be from the original 3.10.0 branch. It's unlikely to compile and will probably need backporting from 4.1.
Your best bet is probably to backport the driver yourself and build it out of tree - a lot simpler than building a whole kernel just for one driver.
All very good points, but I have never pulled a module and built it out of tree before, and so right now the easier proposition for me is to just tweak a config file and try to rebuild the entire kernel. At some point I may try to do what you're suggesting.
I did have a look and find these directions to help me: https://wiki.centos.org/HowTos/BuildingKernelModules
...the above link will likely be my next step after just trying to rebuild the kernel itself.
Peter
On 4 October 2015 at 00:43, Peter peter@pajamian.dhs.org wrote:
All very good points, but I have never pulled a module and built it out of tree before, and so right now the easier proposition for me is to just tweak a config file and try to rebuild the entire kernel. At some point I may try to do what you're suggesting.
I did have a look and find these directions to help me: https://wiki.centos.org/HowTos/BuildingKernelModules
...the above link will likely be my next step after just trying to rebuild the kernel itself.
Peter
I would also recommend that you install the kernel-doc package and then study the relevant files therein.
Alan.
Am 03.10.2015 um 23:57 schrieb Ned Slider ned@unixmail.co.uk:
On 03/10/15 13:19, Peter wrote:
Is it beyond reason to request certain older drivers be enabled in the i686 kernel for CentOS 7 to help support the older hardware that you might find in 32 bit machines? I have an old gateway laptop that I'm trying it out on and it needs the b43 driver enabled.
Thanks,
Peter
The main issue here is one of security.
There is no responsibility on Red Hat to maintain drivers disabled in the RHEL7 kernel, so if CentOS enables drivers for a 32-bit kernel build that are disabled by default in the RHEL kernel, then CentOS would need to take responsibility/ownership for maintaining those drivers within the CentOS kernel, backporting security fixes as necessary.
That is a very different proposition than just rebuilding upstream sources, requiring a very different skill set and resources.
a candidate for a centosplus kernel, where such modification (enabling modules) were done. Implies a disclaimer; "not for production ..."
Further, down the line you will most likely find that the driver won't compile when enabled. For example, the wireless stack has been updated in the RHEL7.2beta kernel from kernel-4.1-rc6, yet the b43 driver in the kernel source will still be from the original 3.10.0 branch. It's unlikely to compile and will probably need backporting from 4.1.
Your best bet is probably to backport the driver yourself and build it out of tree - a lot simpler than building a whole kernel just for one driver.
good point.
-- LF
-
Alan Bartlett -
Leon Fauster -
Ned Slider -
Nico Kadel-Garcia -
Peter