Jon Masters writes:
Hi folks, Several people have been asking what /sbin/weak-modules is/does, mostly because it started script spewing the other day (sorry about that!) on kernel updates. weak-modules is part of some driver updates work we're doing at Red Hat and also involves folks working on Fedora Extras "kmod" kernel packaging (see the packaging list archives). Essentially, this and other scripts are part of a system for allowing compatible kernel modules to continue to work after a kernel update occurs - weak-modules is the part that figures out which kernels are compatible with a driver. There's more information (and some out of date packages - look at rawhide for the current latest stuff!) at http://www.kerneldrivers.org/ and I will add documentation for those who were looking for it and could not find any - I'm sorry that's not been done yet. I'm trying to work with the folks at SuSE/Novell to ultimately offer kernel module package authors a standardized packaging process too (over and above what we each do separately) - I'm going to start by introducing a new macro in redhat-rpm-config along the lines agreed between those of us who met up at OLS to discuss driver updates last week. This is not aimed at undermining the work that's been done in Extras - it's just an additional option. If you would like more information, just drop me an email (I'm also jcm@xxxxxxxxxx when wearing my work hat!) or reply to this one.
What exactly is the problem being solved here? I don't see any obvious link to anything on kerneldrivers.org that describes what this stuff does.
I build lirc and ivtv modules each time a new kernel comes out, and I have absolutely no problems doing that. Couldn't be any easier. Piece of cake. I'm not sure what problem needs solving here. I just install the new kernel and kernel-devel packages, run the script that builds a corresponding lirc and ivtv kernel driver packages, pointing the build at the right build directory, then install the driver packages and reboot. Couldn't be simpler.
If someone really wants to make building kernel driver packages easier, they can simply fix THE HORRIBLE UGLY STINKING CRAP code that kernel-devel's %post script uses to hardlink the identical kernel source files.
If I set out to do this specific task in the most grossly inefficient manner possible, there's no way I could do it any better than the existing mess. The brain-damaged script literally reads the entire /usr/src/kernels, by forking thousands of mind-numbing child procs. And, the more kernels you have installed, the slooower and sloooooooooooooower everything takes.
Has anyone ever heard of this thing called an SHA1 hash? Anybody? Hello!!! McFly!!! Anybody home????You don't really need to be a rocket science in order to figure out that the right way to do this is hash every file in the kernel-devel subpackage (after all, if it's good enough for %config, it's good enough for /usr/src/kernels), add a single file containing all the hash to the kernel-devel subpackage, then have %post simply compare this file against the hash file from other kernel-devel packages, thus knowing immediately, and instantly, what needs to be hardlinked to what, without grepping the entire bloody /usr/src/kernels tree.
This gets old very quickly when you have to install both the SMP and UP kernel-devel packages, for each kernel release.
Attachment:
pgpqmCNY9NIs4.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
