On Mon, 2007-05-21 at 18:50 +0200, Uwe Bugla wrote:
quoted text
> Am Montag, 21. Mai 2007 18:37 schrieben Sie:
> > On 5/21/07, Ken Chen <kenchen@google.com> wrote:
> > > yes and no. in that commit, I automatically create n+1 device when
> > > loop device n is created, allergically was tested to be fine with
> > > casual usage of "losetup" and "mount -o loop".  However, there is a
> > > bug in that commit when loop.c was compiled as a module.  And when Al
> > > fixed it, he also removed that magic "n+1" trick.
> > >
> > > Nevertheless, yes, I'm guilty of introducing the new behavior.
> >
> > The easiest way is to reinstate max_loop and create "max_loop" device
> > up front at module load time.  However, that will lose all the "fancy
> > on-demand device instantiation feature".
> >
> > So I propose we do the following:
> >
> > 1. have the module honor "max_loop" parameter and create that many
> > device upfront on module load (max_loop will also be a hard max) iff
> > user specify the parameter.
> > 2. if max_loop is not specified, default create 8 loop device.  User
> > can extent more loop device by create device node themselves and have
> > kernel automatically instantiate loop device on-demand.
> 
> Sorry, Ken:
> My question on point 2 would be: Does "User can extent more loop device by 
> create device node themselves and......." correspond or conflict to working 
> with udev?

Udev shouldn't care if the kernel tells udev about the new device, and
the node with the correct dev_t is already there, it will leave it as it
is, and only apply the configured user,group,mode values.

The loop tools should probably extended to be able to request new
devices from the kernel in a different way than open().

Kay

-
unsubscribe notice
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/