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

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <ac3eb2510904171124h11c4c70bu371fa06127cb45da@mail.gmail.com>
Date:	Fri, 17 Apr 2009 20:24:32 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Vladislav Bolkhovitin <vst@...b.net>
Cc:	James Smart <James.Smart@...lex.com>,
	Daniel Debonzi <debonzi@...ux.vnet.ibm.com>,
	"scst-devel@...ts.sourceforge.net" <scst-devel@...ts.sourceforge.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>
Subject: Re: [Scst-devel] Discussion about SCST sysfs layout and 
	implementation.

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?

Thanks,
Kay
--
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/