Marc Mutz wrote: > On Thursday 07 March 2002 11:06, Erno Kuusela wrote: > > and CONFIG_BLK_DEV_LOOP=n. > > This should probably read =m. I can't think of a reason why the stock > loop driver shouldn't be compiled, since you can always decide what > loop driver to load t modprobe time. CONFIG_BLK_DEV_LOOP=n is the correct way as then there will be only one loop.o module for each kernel version. If kernel is configured with CONFIG_KMOD=y as recommended by README file, there is no need to modprobe the loop.o module. Kernel will load that automatically on demand. > > so it's a no-no to have the stock loop driver is compiled as a module > > (but unused)? why is this? > > If this were correct, Jari's claim that loop-AES works with distributor > kernels wouldn't hold, since they all compile loop.o as module (they > compile _everything_ as modules ;-). Loop-AES README says that you must recompile and install your kernel before you attempt to compile loop-AES' loop.o module. README also tries to explain why that is needed. There are many ways things can go wrong if that is not done. > On Thursday 07 March 2002 14:02, Juan Quintela wrote: > > This is if you are compiling loop-AES outside of the kernel, you need > > loop module from loop-AES. > > So what? You can overwrite the original loop.o without problems. It > sitll doesn't make sense to me why CONFIG_BLK_DEV_LOOP=n should be a > requirement... (!y, obviously, but =m should be OK). Reason why CONFIG_BLK_DEV_LOOP=m is bad, is that if user does "make modules && make modules_install" on kernel source tree, kernel Makefile will happily copy its loop.o to /lib/modules/WHATEVER tree. And then you have _two_ loop.o modules sitting there. Fortunately depmod/modprobe utilities are smart enough not to puke if that happens. Regards, Jari Ruusu <jari.ruusu@pp.inet.fi> - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
