linux-kernel - Re: An idea .... with code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 27 Aug 2008 05:38:48 -0700 (PDT)
From:	jassi brar <jassi_singh_brar@...oo.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: An idea .... with code

--- On Wed, 8/27/08, Andi Kleen <andi@...stfloor.org> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/