linux-kernel - Re: [RFC][PATCH] perf: sysfs type id

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]

Date:	Wed, 10 Nov 2010 02:59:16 +0100
From:	Kay Sievers <kay.sievers@...y.org>
To:	michael@...erman.id.au
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCH] perf: sysfs type id

On Wed, Nov 10, 2010 at 02:45, Michael Ellerman <michael@...erman.id.au> wrote:
> On Wed, 2010-11-10 at 02:19 +0100, Kay Sievers wrote:
>> On Wed, Nov 10, 2010 at 02:10, Michael Ellerman <michael@...erman.id.au> wrote:
>> > On Wed, 2010-11-10 at 01:57 +0100, Kay Sievers wrote:
>> >> Stay on the list please, with any possible reply. Thanks!
>> >
>> > You dropped the CC when you replied, or is my mailer being weird?
>>
>> You replied to me only:
>>   From: Michael Ellerman <michael@...erman.id.au>
>>   To: Kay Sievers <kay.sievers@...y.org>
>
> Because you replied to me only, or at least that's what I see at my end.

Sure, I don't add lists back when people reply to me only. You never
know why they do that, and if they have a reason for it. That's why I
added the the same mail:
  "Stay on the list please, with any possible reply. Thanks!"

>> Devices can never be on two subsystems at the same time. Not with
>> classes, not with buses, that was never, and probably will never be
>> possible.
>
> OK, I guess I'm getting my terminology wrong. My devices, which show up
> in /sys/class/foo are symlinks into /sys/devices/virtual/foo, so they
> _appear_ to be in two places.
>
> I also see entries for example in /sys/class/scsi_disk that link
> into /sys/devices/pci.

Sure, all devices (devices are real directories) end up in the tree in
/sys/devices/. That's one tree, where all the devices from different
subsystems stack on top of others.

All devices have a symlink called 'subsystem' which points back to the
individual class the device belongs to.

To find all device of a specific subsystem, you start at the subsystem
directory (class/bus) which collects them (only symlinks to the
device, not directories).

That way you will find a blockdev, even when it's deep down in a chain
of devices:
  pci:bridge/pci:dev/scsi:host/scsi:target/scsi:lun/block

All devices get announced to userspace only by their devpath, never by
their class or bus directory. If you wan to watch the stuff in action,
run:
  udevadm monitor --kernel
and plug in a USB stick. You see that you get all device only at one
place created, the rest (which you can't see in the event) is
symlinks, which don't matter for the device itself, only for userspace
tasks to find them.

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/