e.gorodinsky at gmail.com
Fri Sep 11 15:09:17 UTC 2009
Come to think about it, it still is more beneficial to load the loop
device as a module, rather than having it compiled into the kernel,
since all that really is needed to be done to enable the loop device
at boot (after it has been compiled as a module), is to insert the
module name into /etc/modules, and that also allows to unload the
module, reload it with different parameters etc. Of course having
options in /sys is also a good idea, however it won't make it possible
to disable the loop device in case one wants to do this (for example
if one is working on extending its functionality).
2009/9/7 Scott James Remnant <scott at canonical.com>:
> On Mon, 2009-09-07 at 05:57 -0400, Pete Graner wrote:
>> Eugene Gorodinsky wrote:
>> > Sorry, I meant nobody had stated the reasons for compiling the loop
>> > device into the kernel. Or was that the reason to compile it in rather
>> > than the reason to not compile it in?
>> It was done primarily as an effort to link in all common modules across
>> all kernels. It was perhaps an oversight since increasing loop devs is a
>> real need.
> It's compiled in because we have no method for on-demand loading of this
> module. If you don't compile it in, loop devices will fail to mount
> unless you run "modprobe loop" somewhere.
> I don't see any reason why this module cannot expose its configuration
> parameter in /sys to be adjustable at run time. Better still, source
> the LKML patches to make loop devices simply dynamic (so we don't always
> have a fixed number).
> Scott James Remnant
> scott at canonical.com
More information about the kernel-team