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] [day] [month] [year] [list]
Message-ID: <ac3eb2510810301417i60d6e68cv8b9545c29db8018a@mail.gmail.com>
Date:	Thu, 30 Oct 2008 22:17:03 +0100
From:	"Kay Sievers" <kay.sievers@...y.org>
To:	"Andrey Borzenkov" <arvidjaar@...l.ru>
Cc:	linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: 2.6.28-rc2 - strange (redundant) sysfs paths for SCSI

On Wed, Oct 29, 2008 at 19:05, Andrey Borzenkov <arvidjaar@...l.ru> wrote:
> Running with PATA driver:
>
> /sys/devices/pci0000:00/0000:00:04.0/host0/scsi_host/host0
> /sys/devices/pci0000:00/0000:00:04.0/host0/target0:0:0/0:0:0:0
>
> well, in both cases at least one component is redundant?

Yes, it's a duplication. Ideally all the scsi_* class devices would
just offer their attributes at the "real" devices, the bus devices,
and not exist at all. But it's that way for a long time now, and they
can not just be removed. One possible solution could be to create the
attributes of the class devices at the "real" devices, and keep
compatibility symlinks from the class directory to the "real" device.

> Also the intermediate nodes (scsi_host and target0:0:0) do not seem
> to contain any useful information at all?

The target represents a main scsi device object and is expected to be
there. It's part of the specification, and the way scsi works. You can
have multiple targets per host and below the target the devices. All
that might not really make sense for ATA drives mapped to scsi, but
that's not a problem scsi could solve. :)

As mentioned a few lines above, the scsi_host class device "host0" is
already represented as the host bus device "host0" and is a
duplication, that's correct. Same is true for the scsi_device class
device.

The actual directory named "scsi_host" is just the glue the
driver-core creates for all class devices which have a bus device as a
parent. It's not created by scsi. The same thing like your pci
ethernet card is a "pci*" device and the "eth0" device, which is a
child of the pci device, lives in a subdir, always called after the
subsytem, "net". That way network devices can get almost any name
without conflicting with an attribute name of the parent device.
People complained, that they couldn't rename their network interface
to "irq". :)

> I noticed this because kernel installer in Mandriva started to
> complaint about host* and target* device nodes under /sys/bus/scsi/devices:

Yeah, users of sysfs are always required to check what the type of
device they retrieve. It must always be allowed to add new stuff to
existing directories. The host and target devices belong to the scsi
bus and got added a while ago. In the past, they have been created in
the device tree only, without a subsystem attached, and with no events
to userspace, which isn't a good thing to do.

> lrwxrwxrwx 1 root root 0 2008-10-29 19:58 0:0:0:0 -> ../../../devices/pci0000:00/0000:00:04.0/host0/target0:0:0/0:0:0:0/
> lrwxrwxrwx 1 root root 0 2008-10-29 19:58 1:0:0:0 -> ../../../devices/pci0000:00/0000:00:04.0/host1/target1:0:0/1:0:0:0/
> lrwxrwxrwx 1 root root 0 2008-10-29 19:58 host0 -> ../../../devices/pci0000:00/0000:00:04.0/host0/
> lrwxrwxrwx 1 root root 0 2008-10-29 19:58 host1 -> ../../../devices/pci0000:00/0000:00:04.0/host1/
> lrwxrwxrwx 1 root root 0 2008-10-29 19:58 target0:0:0 -> ../../../devices/pci0000:00/0000:00:04.0/host0/target0:0:0/
> lrwxrwxrwx 1 root root 0 2008-10-29 19:58 target1:0:0 -> ../../../devices/pci0000:00/0000:00:04.0/host1/target1:0:0/
>
> It is really not quite clear what use they have.

That looks all totally fine. The only things one could argue about are
the 1:1 duplicated class devices scsi_device and scsi_host, which you
don't even see in this listing, because they are class devices.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ