Re: ELRepo and kernel modules (was WIFI REALTEK RLT8187B)

2010-01-13 Thread Phil Perry

On 01/13/2010 04:49 PM, Troy Dawson wrote:

Phil Perry wrote:

On 01/13/2010 03:14 PM, Troy Dawson wrote:

Alan Bartlett wrote:

2010/1/12 Akemi Yagi :

On Tue, Jan 12, 2010 at 2:08 PM, g  wrote:

Akemi Yagi wrote:

Just a note about the ndiswrapper package from the ELRepo
repository.
It comes with a kernel-version independent, kABI-tracking kernel
module.

i believe all packages from 'elrepo' are kernel independent.

i have 2 packages from them that have gone thru 3 kernel updates
and are working just fine like day they were first installed.

Yes, all kmod packages from ELRepo are kernel independent and should
survive kernel updates quietly. :)

To expand upon Akemi's comment regarding kmod packages from ELRepo --

All kmod packages are built to be kernel independent, kABI tracking
for all the released RHEL 5 kernels (unless otherwise stated). Hence
ELRepo kmod packages are appropriate for all RHEL 5 based derivatives,
i.e. Scientific Linux 5 and CentOS 5, as long as their kernels do not
deviate from the ABI published by TUV.

A brief note about ELRepo, for users of Scientific Linux. ELRepo is
entirely independent of (and is not endorsed by) Red Hat and the
CentOS project. It is, however, acknowledged by both and there is a
communication / co-operation channel to the relevant kernel
engineering team at Red Hat. The ELRepo admin team have significant
experience with RHEL, Scientific Linux and CentOS.

Alan.

Hi Alan,
Thank you for explanation. I have to admit that I hadn't looked at
ELRepo before today, although I've heard of it. It looks very useful for
people who need drivers.
A couple of questions
I see you have both nvidia-x11-drv as well as kmod-nvidia. Are these
independant, or do you have to have both installed?

I am somewhat new to kABI kernel modules. I know the theory, but not
much else.
In your experience with RHEL5, how often has RedHat broken or modified
the ABI's, requiring you to update your kmod package?

Troy


Hi Troy,

If I may be permitted to answer as maintainer of the ELRepo nvidia
packages.

Generally, our (elrepo's) kmod packages only provide the kernel
module(s) (driver.ko), and associated depmod.d .conf entry. The nvidia
package is a little different as there are also the accompanying
proprietary X11 libs, in this case provided by the conventional
nvidia-x11-drv RPM package. So to answer your question, kmod-nvidia
requires nvidia-x11-drv, and vice versa, so they must both be installed.

Your second question is an interesting one, and Alan may be better
qualified to give a more technically correct explanation, but I'll do
my best knowing he'll correct me where I slip up :)

Generally, kABI should be consistent across all kernel releases within
a Red Hat release. So, for example, the kABI of RHEL5 should not
change throughout the life of the product. But as you may suspect,
that is not always the case.

We have built around 60 kmod packages, and from that experience we
have found that the kABI is always consistent within an update release
(e.g, 5.0, 5.1, 5.2 etc). For example, we have not, and would not
expect to observe any kABI breakage for kernels released under the
update release 5.4 (2.6.18-164.x). What we have observed is some
breaking of the kABI *between* update releases.

Generally, the vast majority of our packages work fine across all
kernel update releases (5.0 through to 5.4, at present). However,
there are some exceptions. Nvidia, for example, is one. The current
kmod-nvidia release was built against kernel-2.6.18-128.el5 (5.3), and
is not compatible with earlier kernel releases, suggesting that some
kABI breakage occurred for the 5.3 release that affects kmod-nvidia.
Interesting, kmod-nvidia works seamlessly going forward to 5.4 so in
this instance there was no change in the kABI (affecting kmod-nvidia)
between 5.3 and 5.4. In this instance we simply have a Requires: on
the kmod-nvidia package for kernel >= 2.6.18-128. If users are stuck
on older kernels for any reason and need kmod-nvidia, then we could in
theory build a version-release for them compiled against the kernel
release required although such a situation hasn't arisen yet.

Some other larger packages such as kmod-alsa and kmod-video4linux that
provide hundreds of modules exhibit minor kABI breakage where, when
built against the latest kernel, a few modules then don't weak-link
against earlier kernels due to kABI breakage affecting only those
modules.

But for the vast majority of modules, the kABI is consistent as you
would hope (expect), and a kmod package will work seamlessly across
all kernel releases. In fact, I can't recall any other package
affected by a change in the kABI.

Finally, we would welcome you to join the elrepo mailing lists (and
any other SL users). I don't know how many (non kABI-tracking) kmod
type packages you currently have within SL (if any), but I would
imagine the main benefit of kABI-tracking kmods for someone like
yourself would be that you would only need to build them once r

Re: ELRepo and kernel modules (was WIFI REALTEK RLT8187B)

2010-01-13 Thread Alan Bartlett
2010/1/13 Troy Dawson :

> Hi Alan,
> Thank you for explanation.  I have to admit that I hadn't looked at ELRepo
> before today, although I've heard of it.  It looks very useful for people
> who need drivers.
> A couple of questions
> I see you have both nvidia-x11-drv as well as kmod-nvidia.  Are these
> independant, or do you have to have both installed?
>
> I am somewhat new to kABI kernel modules.  I know the theory, but not much
> else.
> In your experience with RHEL5, how often has RedHat broken or modified the
> ABI's, requiring you to update your kmod package?
>
> Troy

Hi Troy,

Sorry I didn't reply earlier . . .

Having read Phil's comprehensive reply there is very little for me to
say and nothing for me to correct. :-)

Just one comment about Red Hat's published kABI. They will never
remove a symbol from it -- what was present in the original EL5
kernel-2.6.18-8.el5 is present in kernel-2.6.18-164.10.1.el5. When a
new point is released, there may be new ksyms added to the published
ABI -- so it evolves over time.

Regards,
Alan.


Re: ELRepo and kernel modules (was WIFI REALTEK RLT8187B)

2010-01-13 Thread Troy Dawson

Phil Perry wrote:

On 01/13/2010 03:14 PM, Troy Dawson wrote:

Alan Bartlett wrote:

2010/1/12 Akemi Yagi :

On Tue, Jan 12, 2010 at 2:08 PM, g  wrote:

Akemi Yagi wrote:

Just a note about the ndiswrapper package from the ELRepo repository.
It comes with a kernel-version independent, kABI-tracking kernel
module.

i believe all packages from 'elrepo' are kernel independent.

i have 2 packages from them that have gone thru 3 kernel updates
and are working just fine like day they were first installed.

Yes, all kmod packages from ELRepo are kernel independent and should
survive kernel updates quietly. :)

To expand upon Akemi's comment regarding kmod packages from ELRepo --

All kmod packages are built to be kernel independent, kABI tracking
for all the released RHEL 5 kernels (unless otherwise stated). Hence
ELRepo kmod packages are appropriate for all RHEL 5 based derivatives,
i.e. Scientific Linux 5 and CentOS 5, as long as their kernels do not
deviate from the ABI published by TUV.

A brief note about ELRepo, for users of Scientific Linux. ELRepo is
entirely independent of (and is not endorsed by) Red Hat and the
CentOS project. It is, however, acknowledged by both and there is a
communication / co-operation channel to the relevant kernel
engineering team at Red Hat. The ELRepo admin team have significant
experience with RHEL, Scientific Linux and CentOS.

Alan.

Hi Alan,
Thank you for explanation. I have to admit that I hadn't looked at
ELRepo before today, although I've heard of it. It looks very useful for
people who need drivers.
A couple of questions
I see you have both nvidia-x11-drv as well as kmod-nvidia. Are these
independant, or do you have to have both installed?

I am somewhat new to kABI kernel modules. I know the theory, but not
much else.
In your experience with RHEL5, how often has RedHat broken or modified
the ABI's, requiring you to update your kmod package?

Troy


Hi Troy,

If I may be permitted to answer as maintainer of the ELRepo nvidia packages.

Generally, our (elrepo's) kmod packages only provide the kernel 
module(s) (driver.ko), and associated depmod.d .conf entry. The nvidia 
package is a little different as there are also the accompanying 
proprietary X11 libs, in this case provided by the conventional 
nvidia-x11-drv RPM package. So to answer your question, kmod-nvidia 
requires nvidia-x11-drv, and vice versa, so they must both be installed.


Your second question is an interesting one, and Alan may be better 
qualified to give a more technically correct explanation, but I'll do my 
best knowing he'll correct me where I slip up :)


Generally, kABI should be consistent across all kernel releases within a 
Red Hat release. So, for example, the kABI of RHEL5 should not change 
throughout the life of the product. But as you may suspect, that is not 
always the case.


We have built around 60 kmod packages, and from that experience we have 
found that the kABI is always consistent within an update release (e.g, 
5.0, 5.1, 5.2 etc). For example, we have not, and would not expect to 
observe any kABI breakage for kernels released under the update release 
5.4 (2.6.18-164.x). What we have observed is some breaking of the kABI 
*between* update releases.


Generally, the vast majority of our packages work fine across all kernel 
update releases (5.0 through to 5.4, at present). However, there are 
some exceptions. Nvidia, for example, is one. The current kmod-nvidia 
release was built against kernel-2.6.18-128.el5 (5.3), and is not 
compatible with earlier kernel releases, suggesting that some kABI 
breakage occurred for the 5.3 release that affects kmod-nvidia. 
Interesting, kmod-nvidia works seamlessly going forward to 5.4 so in 
this instance there was no change in the kABI (affecting kmod-nvidia) 
between 5.3 and 5.4. In this instance we simply have a Requires: on the 
kmod-nvidia package for kernel >= 2.6.18-128. If users are stuck on 
older kernels for any reason and need kmod-nvidia, then we could in 
theory build a version-release for them compiled against the kernel 
release required although such a situation hasn't arisen yet.


Some other larger packages such as kmod-alsa and kmod-video4linux that 
provide hundreds of modules exhibit minor kABI breakage where, when 
built against the latest kernel, a few modules then don't weak-link 
against earlier kernels due to kABI breakage affecting only those modules.


But for the vast majority of modules, the kABI is consistent as you 
would hope (expect), and a kmod package will work seamlessly across all 
kernel releases. In fact, I can't recall any other package affected by a 
change in the kABI.


Finally, we would welcome you to join the elrepo mailing lists (and any 
other SL users). I don't know how many (non kABI-tracking) kmod type 
packages you currently have within SL (if any), but I would imagine the 
main benefit of kABI-tracking kmods for someone like yourself would be 
that you would only need to build them once r

Re: ELRepo and kernel modules (was WIFI REALTEK RLT8187B)

2010-01-13 Thread Phil Perry

On 01/13/2010 03:14 PM, Troy Dawson wrote:

Alan Bartlett wrote:

2010/1/12 Akemi Yagi :

On Tue, Jan 12, 2010 at 2:08 PM, g  wrote:

Akemi Yagi wrote:

Just a note about the ndiswrapper package from the ELRepo repository.
It comes with a kernel-version independent, kABI-tracking kernel
module.

i believe all packages from 'elrepo' are kernel independent.

i have 2 packages from them that have gone thru 3 kernel updates
and are working just fine like day they were first installed.

Yes, all kmod packages from ELRepo are kernel independent and should
survive kernel updates quietly. :)


To expand upon Akemi's comment regarding kmod packages from ELRepo --

All kmod packages are built to be kernel independent, kABI tracking
for all the released RHEL 5 kernels (unless otherwise stated). Hence
ELRepo kmod packages are appropriate for all RHEL 5 based derivatives,
i.e. Scientific Linux 5 and CentOS 5, as long as their kernels do not
deviate from the ABI published by TUV.

A brief note about ELRepo, for users of Scientific Linux. ELRepo is
entirely independent of (and is not endorsed by) Red Hat and the
CentOS project. It is, however, acknowledged by both and there is a
communication / co-operation channel to the relevant kernel
engineering team at Red Hat. The ELRepo admin team have significant
experience with RHEL, Scientific Linux and CentOS.

Alan.


Hi Alan,
Thank you for explanation. I have to admit that I hadn't looked at
ELRepo before today, although I've heard of it. It looks very useful for
people who need drivers.
A couple of questions
I see you have both nvidia-x11-drv as well as kmod-nvidia. Are these
independant, or do you have to have both installed?

I am somewhat new to kABI kernel modules. I know the theory, but not
much else.
In your experience with RHEL5, how often has RedHat broken or modified
the ABI's, requiring you to update your kmod package?

Troy


Hi Troy,

If I may be permitted to answer as maintainer of the ELRepo nvidia packages.

Generally, our (elrepo's) kmod packages only provide the kernel 
module(s) (driver.ko), and associated depmod.d .conf entry. The nvidia 
package is a little different as there are also the accompanying 
proprietary X11 libs, in this case provided by the conventional 
nvidia-x11-drv RPM package. So to answer your question, kmod-nvidia 
requires nvidia-x11-drv, and vice versa, so they must both be installed.


Your second question is an interesting one, and Alan may be better 
qualified to give a more technically correct explanation, but I'll do my 
best knowing he'll correct me where I slip up :)


Generally, kABI should be consistent across all kernel releases within a 
Red Hat release. So, for example, the kABI of RHEL5 should not change 
throughout the life of the product. But as you may suspect, that is not 
always the case.


We have built around 60 kmod packages, and from that experience we have 
found that the kABI is always consistent within an update release (e.g, 
5.0, 5.1, 5.2 etc). For example, we have not, and would not expect to 
observe any kABI breakage for kernels released under the update release 
5.4 (2.6.18-164.x). What we have observed is some breaking of the kABI 
*between* update releases.


Generally, the vast majority of our packages work fine across all kernel 
update releases (5.0 through to 5.4, at present). However, there are 
some exceptions. Nvidia, for example, is one. The current kmod-nvidia 
release was built against kernel-2.6.18-128.el5 (5.3), and is not 
compatible with earlier kernel releases, suggesting that some kABI 
breakage occurred for the 5.3 release that affects kmod-nvidia. 
Interesting, kmod-nvidia works seamlessly going forward to 5.4 so in 
this instance there was no change in the kABI (affecting kmod-nvidia) 
between 5.3 and 5.4. In this instance we simply have a Requires: on the 
kmod-nvidia package for kernel >= 2.6.18-128. If users are stuck on 
older kernels for any reason and need kmod-nvidia, then we could in 
theory build a version-release for them compiled against the kernel 
release required although such a situation hasn't arisen yet.


Some other larger packages such as kmod-alsa and kmod-video4linux that 
provide hundreds of modules exhibit minor kABI breakage where, when 
built against the latest kernel, a few modules then don't weak-link 
against earlier kernels due to kABI breakage affecting only those modules.


But for the vast majority of modules, the kABI is consistent as you 
would hope (expect), and a kmod package will work seamlessly across all 
kernel releases. In fact, I can't recall any other package affected by a 
change in the kABI.


Finally, we would welcome you to join the elrepo mailing lists (and any 
other SL users). I don't know how many (non kABI-tracking) kmod type 
packages you currently have within SL (if any), but I would imagine the 
main benefit of kABI-tracking kmods for someone like yourself would be 
that you would only need to build them once rather than having

ELRepo and kernel modules (was WIFI REALTEK RLT8187B)

2010-01-13 Thread Troy Dawson

Alan Bartlett wrote:

2010/1/12 Akemi Yagi :

On Tue, Jan 12, 2010 at 2:08 PM, g  wrote:

Akemi Yagi wrote:

Just a note about the ndiswrapper package from the ELRepo repository.
It comes with a kernel-version independent, kABI-tracking kernel
module.

i believe all packages from 'elrepo' are kernel independent.

i have 2 packages from them that have gone thru 3 kernel updates
and are working just fine like day they were first installed.

Yes, all kmod packages from ELRepo are kernel independent and should
survive kernel updates quietly. :)


To expand upon Akemi's comment regarding kmod packages from ELRepo --

All kmod packages are built to be kernel independent, kABI tracking
for all the released RHEL 5 kernels (unless otherwise stated). Hence
ELRepo kmod packages are appropriate for all RHEL 5 based derivatives,
i.e. Scientific Linux 5 and CentOS 5, as long as their kernels do not
deviate from the ABI published by TUV.

A brief note about ELRepo, for users of Scientific Linux. ELRepo is
entirely independent of (and is not endorsed by) Red Hat and the
CentOS project. It is, however, acknowledged by both and there is a
communication / co-operation channel to the relevant kernel
engineering team at Red Hat. The ELRepo admin team have significant
experience with RHEL, Scientific Linux and CentOS.

Alan.


Hi Alan,
Thank you for explanation.  I have to admit that I hadn't looked at 
ELRepo before today, although I've heard of it.  It looks very useful 
for people who need drivers.

A couple of questions
I see you have both nvidia-x11-drv as well as kmod-nvidia.  Are these 
independant, or do you have to have both installed?


I am somewhat new to kABI kernel modules.  I know the theory, but not 
much else.
In your experience with RHEL5, how often has RedHat broken or modified 
the ABI's, requiring you to update your kmod package?


Troy
--
__
Troy Dawson  daw...@fnal.gov  (630)840-6468
Fermilab  ComputingDivision/LSCS/CSI/USS Group
__