On Jul 8, 2010, at 19:11 , Dag Wieers wrote:

> On Thu, 8 Jul 2010, Troy Dawson wrote:
> 
>> Dag Wieers wrote:
>>> On Thu, 8 Jul 2010, Troy Dawson wrote:
>>> >  With many minor releases, we update the version of openafs for that >  minor release.  This new version then get's pushed out to the rest of >  the releases.
>>> >  With SL 5.5 we updated openafs to 1.4.12, and we are about to push that >  version out to the rest of the SL5 releases.  It currently is in >  testing, and it has passed every updating test I could think to throw at >  it and it updated without any problems.
>>> > >  We plan on pushing this out on Monday - 12 July 2010
>>> > >  To test or update
>>> > >  SL5
>>> >  -------
>>> > >        yum --enablerepo=sl-testing update kernel-module-openafs\*
>>> > >  or you can download rpm's by hand at
>>> > > http:  //ftp.scientificlinux.org/linux/scientific/5rolling/testing/i386/openafs/
>>> > http:  //ftp.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/openafs/
>>> 
>>> Would there be any interest if we provided kmod-openafs modules that are
>>> kernel-agnostic (or kABI-tracking as we say) from ELRepo ?
>>> 
>>> The advantage is that the modules keep on working through kernel-updates,
>>> which makes update-cycles (and maintenance) to be less work.
>>> 
>>> I am tempted to create those packages, but without an interested party
>>> that can provide sufficient testing the effort is kinda moot.
>>> 
>>> Let me know,
>> 
>> I thought that the openafs kernel modules didn't work well with kABI, but I would love to find that incorrect.  If you think it is possible, please build it, and I'm certain we'll have plenty of testers.
> 
> If that is true we might have a discussion with Red Hat to see whether we can have those symbols as part of the kABI whitelist. Let's find out :-)

There are symbols missing from the whitelist, so there was no way to use kABI-tracking modules "cleanly". That being said, it probably would have worked. If someone has the time, it would be really interesting to force the module built for the SL5.0 GA kernel into -194.8.1 and see whether that works.

The guy in charge at Red Hat (Jon Masters) seems very openminded, so talking to them is certainly worth the effort. I have my doubts though whether there's any chance to have the whitelist extended while it still matters.

>> For SL5, I'd like to stick with what we have with the supported release, but I'm very sure that we would have plenty of users wiling to test and use the kmod-openafs module.  If everything goes well, we could offer it as an alternative.
>> 
>> For SL6, if this works we could use that and save us from having to create kernel modules with each kernel update.
> 
> Sure, I don't want to force anyone anyway. A clean upgrade path will be very hard due to the fact that these kernel-module packages have the kernel-version in the name. So your position makes a lot of sense.

That's my point of view as well. SL5 should not drop the kernel-module packages (at least not anytime soon), but having kmods for testing would be very useful. With SL6, AFAIK, the whitelist problem is going to vanish, and IMO we should use kABI for the next major release if at all possible.

We should also make an effort to (re-)unite the SL/Elrepo/... packaging with the one from openafs.org. And Christof Hanke, who's crafting the OpenSuSE RPMs, also expressed interest in a unified spec during the European AFS Workshop in Rome last autumn. This is probably the time to actually try getting there. It may turn out that it's not feasible, but let's try.

Opinions?

> 
> -- 
> --   dag wieers,  [log in to unmask],  http://dag.wieers.com/   --
> [Any errors in spelling, tact or fact are transmission errors]

-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany