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: <49E8A551.7050307@linux.vnet.ibm.com>
Date:	Fri, 17 Apr 2009 12:50:41 -0300
From:	Daniel Debonzi <debonzi@...ux.vnet.ibm.com>
To:	Kay Sievers <kay.sievers@...y.org>
CC:	Vladislav Bolkhovitin <vst@...b.net>,
	scst-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org,
	linux-scsi@...r.kernel.org
Subject: Re: [Scst-devel] Discussion about SCST sysfs layout and implementation.

Hi Kay,

Thanks for the inputs.

Do you mean that uses struct device is the right way to do it instead of 
kobjects or it is just a option to get things on right places into sysfs?

I don't know this struct closely but my first impression looking to the 
source code is that it is tied with hardware and has some complexity we 
probably don't need. What do you think?

Regards,
Daniel Debonzi


Kay Sievers wrote:
> On Fri, Apr 17, 2009 at 15:25, Daniel Debonzi
> <debonzi@...ux.vnet.ibm.com> wrote:
>> Vladislav Bolkhovitin wrote:
> 
>>>> Based on all I read this last days, I believe we are not allowed to
>>>> include the directory scsi_tgt on /sys root. I think it has to be in a
>>>> existent directory reserved for this sort of application. I just didn't
>>>> figured out which one it would be.
> 
> Right, there will be no new out-of-/sys/devices/ top-level device dir,
> unless you convince everybody to have a scsifs, which would be in
> /sys/kernel/scsi/, and which would not use the driver core device
> stuff at all. :)
> 
>>> /sys/class? It already has scsi_device, scsi_disk, scsi_generic and
>>> scsi_host.
> 
> If it's a bus or a class, it does not matter. What you need to include
> is a "struct device" (and not a kobject) if you want them to show up
> in the common directories.
> 
>> I don't think so because all the directories on /sys/class have symlinks to
>> the files somewhere else. However I noticed that many of them on my system
>> are on /sys/device/virtual
> 
> All "struct device" devices appear in /sys/devices/, that's the single
> place the hierarchy is expressed. The classification, meaning the
> "collection of devices of the same subsystem" happens in /sys/bus/
> /sys/class/, therefore they are only flat lists of links. Virtual are
> devices which have no parent assigned. The driver core prepends
> virtual to them, when they are registered.
> 
> 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/
> 

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