Shea Levy wrote: First of all, let me stress the main difference between module-init-tools and kmod. The former is a collection of command line utilities, while the latter is a *library* plus a collection of command line utilities provided for backwards compatibility.
This difference was the main reason for me to try another approach. BTW, I moved kmod-MODULE_DIR to kmod-lib-modules. You're welcome to create another branch with your kmod migration code. > On 03/27/2012 01:07 PM, Yury G. Kudryashov wrote: >> Hi! >> >> * Easier to catch buggy kernel module buildsystem. >> | Just use chroot builds. If you're not root, read the makefile(s) >> | carefully. > > By this argument, we should just fully follow FHS. No. I didn't say this. On the other hand, I see nothing bad in following FHS for *system-wide* one- instance services. We already have /etc, /bin/sh and /usr/bin/env, why /lib/modules is worse than /etc? Non-chroot builds can look into /etc, and make strange decisions at configure time. > But bugs DO happen, See below (after your item 3). > >> | We'll need the same patches to buildsystem in both cases. The patches >> | can be accepted upstream and/or shared with mainstream distros. > > Not necessarily. If we use MODULE_DIR, yes, but if we switch to the new > command line flags that kmod's modprobe supports we won't need to patch > kmod. We'll need to patch udev if it doesn't supply a similar command > line flag, of course. The kernel build system can remain as it is now. See above (about library vs utilities). > >> /lib/modules: >> ============= >> * No need to patch: >> - Kernel buildsystem (removing '-b' key); >> | I'm pretty sure that the patch will never be accepted upstream >> - kmod; > > We won't need to patch kmod. OK, we'll have to patch either kmod, or every package that links to libkmod.so and every package that calls `modprobe`. > >> | Same here >> - udev; >> | Same here, if patch needed (see below) >> - more packages to come later. > > If you're allowed to say 'more packages to come later', then I'm allowed > to say 'more kernelPackages that will hard-code /lib/modules' The kernelPackages that hard-code /lib/modules cause no problems if you use chroot builds. The build will fail, and you'll have to patch the buildsystem. > >> | I'm not sure if we need to patch every package, but we definitely need >> | to ensure that every package using libkmod has MODULE_DIR env var set >> | to the desired value. >> - every shell script that has $(find /lib/modules/`uname -r`) > > Yes, but patching these is a GOOD THING since most of them occur in > kernelPackage build scripts. I'm not talking about build scripts, I'm talking about runtime. Sorry that I haven't stated this explicitly. We'll have to patch build scripts in both cases. > >> | I have no well-known example of such script, but kmod has no >> | `modprobe -l` (this switch was deprecated in module-init-tools). >> >> * Easy to switch all running processes to a new module dir. >> | Rarely needed. It it's hard (impossible?) to reload many modules on the >> | fly, and it's rather easy to manually `insmod` a few modules. > > > Some further thoughts: > 1. Purity as a general principle has proven value. I believe the > burden of proof of value is on those who wish to add an impurity. I think that having /lib/modules/`uname -r` invisible to build scripts adds no impurity. The result of each chroot build will depend only on its buildInputs, and the runtime behaviour will depend only on its /nix/store dependencies and system-wide settings like /lib/modules/`uname -r` symlink, /etc, e.t.c.. > 2. The MODULE_DIR approach has precedent and has not, to my > knowledge, caused any significant problems As I've stated above, libkmod is a shared library. This means that the number of binaries that will need to know $MODULE_DIR will grow as more binaries will link to libkmod.so. > 3. Problems in the MODULE_DIR approach generally come in the form > of early failures: Build failure, or a boot fails completely on the > first try. Failures due to a /lib/modules could hide a long time before > surfacing, such is the nature of impure state Could you please provide an example of a package such that: * it leads to an early failure with MODULE_DIR approach; * it doesn't lead to an early failure with /lib/modules approach with chroot builds? I agree to add "doesn't require chroot builds for early buildsystem errors detection" to MODULE_DIR pro's. BTW, I can provide (currently, theoretical) example of a situation when MODULE_DIR approach leads to a hidden failure. Suppose that `foo` executable links to libkmod.so, and we've forgotten to wrap `foo` to set MODULE_DIR in the wrapper. If `foo` is not critical for boot, then nobody will notice the failure. Let me repeat that this situation was not possible with module- init-tools, but it is possible with libkmod. > 4. The 'burden' of patching build systems is inherent in a system > as radical as nix, and is not really that high. We patch shebangs, gcc, > ld.so, etc. etc... Why is it suddenly a problem for udev, the kernel, > etc.? Because we can proceed without these extra patches. -- Yury G. Kudryashov, mailto: ur...@mccme.ru _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
