Re: [PATCH] nbd: nbd sysfs framework

From: Paul Clements
Date: Thu Aug 04 2011 - 12:32:00 EST


On Thu, Aug 4, 2011 at 1:22 AM, Greg KH <greg@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/