On Wed, 16 Apr 2003, Stephen Cameron wrote:
> A certain major linux distribution distributes a number of binary
> kernels, errata kernels, which all report the exact same thing
> via "uname -r". These kernels may differ by only a little
> (only the .config file is different in some small way) or by
> a lot (binary drivers for one don't work (panic) on another).
We've run into the same problems here, with this *unnamed* major Linux distro ;) We distribute pre-compiled versions of open source
drivers that contain additional features or bug fixes that aren't in the standard/included drivers...
> The task for the binary driver distributor becomes to figure out which
> of these multiple errata kernels found in /boot corresponds to the
> /lib/modules directory, so we can drop the binary driver that was
> made for that errata kernel in there, and not a driver made for the
> wrong kernel.
I think you just have to assume that the running kernel is the one that gets its module upgraded (or installed). And that the /lib/modules directory that is in the standard location for that kernel (i.e., it hasn't been moved somewhere else in preparation for installing another kernel) is the one corresponding to the running kernel. This is what we do in our installation process... no one has complained about this behavior as far as I know. I don't know that there's any other sane way to handle this... :/
The truth is, the kernel rpms for this distro are not designed to be installed side by side, they really ought to be upgraded (meaning the old stuff gets removed, so there's no ambiguity). Do you actually have customers that are installing multiple kernels and moving /lib/modules dirs around? (I know we do this in our labs, and you may too, but I can't imagine too many customers doing this...)
> This seems like a lot of contortions to go through and I'm wondering
> if there's a simpler way to identify the contents of /lib/modules,
> aside from the 'uname -r' type string, and I just missed it.
Have you tried "cat /proc/version" ? It's got the build date of the kernel in it...
> Also note, I can't just figure out which is the _running_ kernel
> (by checksumming /boot/vmlinuz, cross-checked against /etc/lilo.conf
> or grub conf file, because in certain situations the running kernel
> is only there to install another kernel. And we want to provide
> the option to install the driver for all the kernels on the system
> that we can (reliably) find.)
Hmm... I'm not sure how feasible that's going to be... Maybe you could just ask customers to run the setup script (or whatever you install with) once they're booted on the kernel that they intend to run the system on? Either that or maybe they just have to tell the setup which kernels they want modules installed for (maybe you give them a proposed list, based upon checking the system)?
Is there any chance that SuSE (oops, let the cat out of the bag ;) would accept your driver(s) into their distribution, or
is this proprietary HP stuff? They've been very helpful in accepting various patches from us...
Anyway, I don't know if any of that helped... this really is a nasty situation to have to deal with... I'm not sure there's any perfect solution... you're probably just going to have to make some assumptions and intelligent guesses and hope for the best!
Good luck...
-- Paul- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Apr 23 2003 - 22:00:19 EST