forked from luck/tmp_suning_uos_patched
e105b8bfc7
Why?: There are occasions where userspace would like to access sysfs attributes for a device but it may not know how sysfs has named the device or the path. For example what is the sysfs path for /dev/disk/by-id/ata-ST3160827AS_5MT004CK? With this change a call to stat(2) returns the major:minor then userspace can see that /sys/dev/block/8:32 links to /sys/block/sdc. What are the alternatives?: 1/ Add an ioctl to return the path: Doable, but sysfs is meant to reduce the need to proliferate ioctl interfaces into the kernel, so this seems counter productive. 2/ Use udev to create these symlinks: Also doable, but it adds a udev dependency to utilities that might be running in a limited environment like an initramfs. 3/ Do a full-tree search of sysfs. [kay.sievers@vrfy.org: fix duplicate registrations] [kay.sievers@vrfy.org: cleanup suggestions] Cc: Neil Brown <neilb@suse.de> Cc: Tejun Heo <htejun@gmail.com> Acked-by: Kay Sievers <kay.sievers@vrfy.org> Reviewed-by: SL Baur <steve@xemacs.org> Acked-by: Kay Sievers <kay.sievers@vrfy.org> Acked-by: Mark Lord <lkml@rtr.ca> Acked-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
21 lines
693 B
Plaintext
21 lines
693 B
Plaintext
What: /sys/dev
|
|
Date: April 2008
|
|
KernelVersion: 2.6.26
|
|
Contact: Dan Williams <dan.j.williams@intel.com>
|
|
Description: The /sys/dev tree provides a method to look up the sysfs
|
|
path for a device using the information returned from
|
|
stat(2). There are two directories, 'block' and 'char',
|
|
beneath /sys/dev containing symbolic links with names of
|
|
the form "<major>:<minor>". These links point to the
|
|
corresponding sysfs path for the given device.
|
|
|
|
Example:
|
|
$ readlink /sys/dev/block/8:32
|
|
../../block/sdc
|
|
|
|
Entries in /sys/dev/char and /sys/dev/block will be
|
|
dynamically created and destroyed as devices enter and
|
|
leave the system.
|
|
|
|
Users: mdadm <linux-raid@vger.kernel.org>
|