[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1179767466.3320.48.camel@lov.localdomain>
Date: Mon, 21 May 2007 19:11:06 +0200
From: Kay Sievers <kay.sievers@...y.org>
To: Uwe Bugla <uwe.bugla@....de>
Cc: Ken Chen <kenchen@...gle.com>, Ray Lee <ray-lk@...rabbit.org>,
Al Viro <viro@....linux.org.uk>,
Andrey Borzenkov <arvidjaar@...l.ru>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Michal Piotrowski <michal.k.k.piotrowski@...il.com>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: bug in 2.6.22-rc2: loop mount limited to one single iso image
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 <kenchen@...gle.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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists