Hi, here's a problem I'm having, perhaps someone has some smart idea...
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).
I seem to be in the business of distributing binary drivers to customers,
like it or not. Since there already exist multiple incompatible
errata kernels that all share the same uname -r and hence the same
directory for modules, and since all these errata kernels *might*
be found on a single machine in /boot.... (only one of which is likely
to be viable, since there is only one /lib/modules directory for
them all)...
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.
So far, the best idea I have come up with is to construct a database
of checksums of all the *.o files in the various /lib/modules directories
that come with the various errata kernels, then compare that database
against what is actually found in /lib/modules. (note, the results will
likely never match _exactly_, since binary driver distributors like myself
can drop .o files in /lib/modules, and alos, this distribution doesn't use
the symbol name checksums, so identical *.o files appear occasionally in
/lib/modules for different errata kernels.) Then count which errata kernel
matches the most *.o files, and assume that must be the one (and probably
should have some minimum numver to match, lest the user have only kernels
we know nothing about)
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.
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.)
Also, rpm -qf to try to id the RPM from which some /lib/modules file
or vmlinuz won't necessarily work, as rpm can report they belong to
multiple RPMs in certain cases.
Thanks for any other ideas.
-- steve
-
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:18 EST