Re: An idea .... with code

[jassi brar]

--- On Wed, 8/27/08, Andi Kleen <andi@xxxxxxxxxxxxxx> wrote:

> I fail to see what your patch generalizes? AFAIK it just
> adds a new
> more narrow (less features than the old one) interface to
> create loop devices.
 Btw, my code is not a patch to the loop driver, its an altogether new module. May i daresay, it aims squarely at drivers/block/loop.c and mean to replace it altogether.
 My module generalizes in the way that it doesn't add or make use of any ioctl. It doesn't even export a variable and makes uses only of what other subsystems provide for(block, sysfs, vfs).
 As far as features are concerned, please suggest me what could be done with /dev/loop0 and not for /dev/vblk?


> But you're adding more code which is more intrusive? 
 To be exact, i mean to _replace_ driver/block/loop.c, and hence _remove_ all the loop specific ioctls and max# limitations, with drivers/block/vblk.c :D



> Your goal is to replace all ioctls with sysfs files? 

  Please do have a look at the code.

 I add only one sysfs interface (manage), which when read returns the status of all the files being emulated and when written updates(add/remove) emulation of a file.
 The interface could be made more useful by echo'ing in other parameters along with filename for example:
echo +[r/w]+[sects]+[cyls]+[heads]+[filename] > /sys/devices/virblk/manage
 for specifyinf readonly, cylinders, heads, sectsize for the file to be emulated.


> If it's that then I'm going on the book as saying
> that's a bad idea, especially
> for this case. While ioctls have their problems they work
> quite well for many 
> things. I don't see any particular reason why ioctls
> should not be used
> to configure loop devices.
  I don't intend to revolt against the concept of ioctls. Being an embedded linux engineer I do understand the importance of ioctls: i declare one every other day for configuring custom h/w: Graphics and Multimedia esp so.
 As for loop devices, i think we can make do without'em.

Regards,
-Jassi


      
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/