linux-kernel - Re: [PATCH] nbd: nbd sysfs framework

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAECXXi4nya8pf-XWCBQcLU1YCM8VDi8Nruu_jUjdNjDm9+8EVQ@mail.gmail.com>
Date:	Thu, 4 Aug 2011 12:31:52 -0400
From:	Paul Clements <paul.clements@...sios.com>
To:	Greg KH <greg@...ah.com>
Cc:	andrew morton <akpm@...ux-foundation.org>,
	kernel list <linux-kernel@...r.kernel.org>,
	nbd-general@...ts.sourceforge.net
Subject: Re: [PATCH] nbd: nbd sysfs framework

On Thu, Aug 4, 2011 at 1:22 AM, Greg KH <greg@...ah.com> wrote:
> On Wed, Aug 03, 2011 at 10:17:04PM -0400, Paul Clements wrote:
>> On Wed, Aug 3, 2011 at 7:34 PM, Greg KH <greg@...ah.com> wrote:
>> > On Wed, Aug 03, 2011 at 07:15:51PM -0400, Paul Clements wrote:
>> >> Description: The patch creates a new sysfs entry framework for nbd.
>> >
>> > Why?  What does this buy us except an increase in code size for no added
>> > benifit?  You seem to be stripping out the driver layer here and using
>> > "raw" kobjects, why?
>>
>> Not sure what I was thinking...just in a hurry, I think.
>>
>> Is the following a little better?
>
> I don't know, I still fail to understand _why_ this patch is needed.
>
> Why are you doing this?  What is the goal?  What is wrong with the
> existing code that it doesn't work for you?

So, first, the point of the framework, as I'm calling it, is (and
several other drivers do similar things...) to avoid the whole kobj to
device to gendisk to driver-specific struct walking in every single
sysfs handler routine. So I've created the meta-structure
nbd_sysfs_entry to allow me to have two routines that do the walking
(and any other common tasks) and then hand off (via function pointer)
to the actual handler for the particular sysfs entry. Consequently,
most of the sysfs entry handlers are just one line long.

The second goal is to avoid adding more ioctls to nbd, as it's already
got enough. Eventually, we may even reduce the number of ioctls in
nbd. Yeah, sysfs is not a panacea, but it tends to be easier to
describe and work with and avoids some of the cross-platform headaches
of ioctls.

Thirdly, support for FUA and FLUSH (and other features) can be added
once we've exposed the nbd device flags via sysfs. This is being
requested by nbd users and has been discussed on nbd-general.

Thanks again for your feedback. I'll add the documentation and other
bits that you asked about.

--
Paul
--
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/