Message-ID: <49F736B3.9090205@vlnb.net>
Date:	Tue, 28 Apr 2009 21:02:43 +0400
From:	Vladislav Bolkhovitin <vst@...b.net>
To:	Kay Sievers <kay.sievers@...y.org>
CC:	"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
	"scst-devel@...ts.sourceforge.net" <scst-devel@...ts.sourceforge.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Daniel Debonzi <debonzi@...ux.vnet.ibm.com>,
	James Smart <James.Smart@...lex.com>
Subject: Re: [Scst-devel] Discussion about SCST sysfs layout and	implementation.

Kay Sievers, on 04/17/2009 10:24 PM wrote:
> On Fri, Apr 17, 2009 at 19:56, Kay Sievers <kay.sievers@...y.org> wrote:
>> On Fri, Apr 17, 2009 at 19:43, Vladislav Bolkhovitin <vst@...b.net> wrote:
>>> Thank you for the suggestion. If nobody objects, we will go with
>>> /sys/class/scst_tgt.
>> On Fri, Apr 17, 2009 at 19:43, Vladislav Bolkhovitin <vst@...b.net> wrote:
>>> I agree, looks like using struct device instead of struct kobject should
>>> additionally complicate the code a lot for not clear gain.
>> Thes both replies together suggest that you miss how sysfs and the
>> driver core works. Please go and read the current code, and look at
>> sysfs, before trying anything like this.
>>
>> There is no way to add any stuff to /sys/class/scst_tgt/ without using
>> proper "struct device" objects.
>>
>> For the same reason we will not have a disconnected device tree, we
>> will not havet any raw kobject in the /sys/devices, /sys/class,
>> /sys/bus directories.
> 
> As a starting point, consider creating a "scst" bus_type. Then make
> sure all devices you need are uniquely named, so they can be in a flat
> list in /sys/bus/scst/devices/.
> 
> Then add all the devices as struct_device to the tree, maybe use an
> existing parent struct_device (like a pci device) if you have one, or
> create a custom one in /sys/devices/ if there is nothing to use.
> 
> All the devices you add will show up in a hierarchy in /sys/devices/
> depending on the parent information you supply, and every single
> device of your subsystem will be listed in a flat list in
> /sys/bus/scst/devices/*. You will also get proper events for userspace
> that way.
> 
> The question is where the actual block devices hang off, and if they
> can use one of the created scst devices, or if they will be virtual
> ones?

After some deep sysfs digging I agree, /sys/class/scst_tgt isn't too 
good place, because SCST as a SCSI subsystem doesn't deal with "devices" 
in the common Linux understanding of this term. Instead, it deals with 
objects, which shouldn't be seen by user space as devices. Closer 
analogy for them is something like NFS exports [1].

What SCST sysfs interface needs is to direct export of internal data 
structures, their attributes and the linkages between them to user 
space. Seems, the appropriate place for such objects is /sys/kernel/. 
So, will /sys/kernel/scst_tgt/ be a good root of the SCST sysfs 
hierarchy? The content of it will remain the same as I described in the 
first e-mail of this thread.

Internal implementation will be based on kobject's and kobj_attribute's 
as in the prototype, developed by Daniel Debonzi (it so far uses 
/sys/scsi_tgt as a root). The end result should be simple, clear and 
straightforward.

Thanks,
Vlad

[1] As I already wrote, there is very few in common between SCSI target 
and initiator subsystems: only some constants and protocol (hence, name 
"SCSI"). This isn't a limitation of this particular implementation, this 
is fundamental. More details you can find in the middle of 
http://lkml.org/lkml/2008/12/10/245.

View attachment "scst_sysfs.c" of type "text/plain" (4987 bytes)

Powered by blists - more mailing lists