From: Daniel Debonzi <debonzi@linux.vnet.ibm.com>
To: Kay Sievers <kay.sievers@vrfy.org>
Cc: Vladislav Bolkhovitin <vst@vlnb.net>,
James Smart <James.Smart@emulex.com>,
"scst-devel@lists.sourceforge.net"
<scst-devel@lists.sourceforge.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: Re: [Scst-devel] Discussion about SCST sysfs layout and implementation.
Date: Thu, 23 Apr 2009 13:11:40 -0300 [thread overview]
Message-ID: <49F0933C.6040009@linux.vnet.ibm.com> (raw)
In-Reply-To: <ac3eb2510904171124h11c4c70bu371fa06127cb45da@mail.gmail.com>
Hi all,
I was off those days due to a long holiday here in Brazil. Now I am
getting back to it.
Kay Sievers wrote:
> On Fri, Apr 17, 2009 at 19:56, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> On Fri, Apr 17, 2009 at 19:43, Vladislav Bolkhovitin <vst@vlnb.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@vlnb.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?
Vlad, how do you think we should move on it?
Do you want me to try to go deeper on it and make a new plan/propose or
would you like to reformulate the RFC you did?
As you all know my knowledge still limited on this subject so I don't
feel comfortable to make this sort of decisions at this moments.
Regards,
Daniel Debonzi
next prev parent reply other threads:[~2009-04-23 16:11 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-16 13:19 [RFC]: SCST sysfs layout Vladislav Bolkhovitin
[not found] ` <49E77795.7080204@linux.vnet.ibm.com>
2009-04-17 10:51 ` [Scst-devel] Discussion about SCST sysfs layout and implementation Vladislav Bolkhovitin
2009-04-17 13:25 ` Daniel Debonzi
2009-04-17 14:12 ` Vladislav Bolkhovitin
2009-04-17 14:27 ` James Smart
2009-04-17 17:43 ` Vladislav Bolkhovitin
2009-04-17 17:56 ` Kay Sievers
2009-04-17 17:56 ` Kay Sievers
2009-04-17 18:24 ` Kay Sievers
2009-04-17 18:24 ` Kay Sievers
2009-04-23 16:11 ` Daniel Debonzi [this message]
2009-04-28 17:02 ` Vladislav Bolkhovitin
2009-04-17 14:24 ` Kay Sievers
2009-04-17 14:24 ` Kay Sievers
2009-04-17 15:50 ` Daniel Debonzi
2009-04-17 16:03 ` Kay Sievers
2009-04-17 16:03 ` Kay Sievers
2009-04-17 17:42 ` Vladislav Bolkhovitin
2009-04-17 17:43 ` Vladislav Bolkhovitin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49F0933C.6040009@linux.vnet.ibm.com \
--to=debonzi@linux.vnet.ibm.com \
--cc=James.Smart@emulex.com \
--cc=kay.sievers@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=scst-devel@lists.sourceforge.net \
--cc=vst@vlnb.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.