Re: [Scst-devel] Discussion about SCST sysfs layout and implementation.

[Daniel Debonzi]

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@xxxxxxxx> wrote:
> > On Fri, Apr 17, 2009 at 19:43, Vladislav Bolkhovitin <vst@xxxxxxxx> 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@xxxxxxxx> 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


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