On Monday 21 May 2007, Kay Sievers wrote: > On Mon, 2007-05-21 at 18:50 +0200, Uwe Bugla wrote: > > Am Montag, 21. Mai 2007 18:37 schrieben Sie: > > > On 5/21/07, Ken Chen <[email protected]> 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(). > Except as already mentioned it will introduce races between tool requesting new device and udev creating new node. We already had this with raw devices. My comparison with /dev/pts was incorrect because it is using internal filesystem that creates devices synchronously. May be all such cases has to be converted to use common file system. mount -t nodefs -o device=pts none /dev/pts mount -t nodefs -o device=loop none /dev/loop
Attachment:
pgpjS1ewmGQIC.pgp
Description: PGP signature
- References:
- Re: bug in 2.6.22-rc2: loop mount limited to one single iso image
- From: Ray Lee <[email protected]>
- Re: bug in 2.6.22-rc2: loop mount limited to one single iso image
- From: Uwe Bugla <[email protected]>
- Re: bug in 2.6.22-rc2: loop mount limited to one single iso image
- From: Kay Sievers <[email protected]>
- Re: bug in 2.6.22-rc2: loop mount limited to one single iso image
- Prev by Date: Re: Race free attributes in sysfs
- Next by Date: Re: [stable] [PATCH] Ignore bogus ACPI info for offline CPUs
- Previous by thread: Re: bug in 2.6.22-rc2: loop mount limited to one single iso image
- Next by thread: Re: bug in 2.6.22-rc2: loop mount limited to one single iso image
- Index(es):
 |