Stefan de Konink wrote:
What was the reason for adding the block device name to the block symlink
if this symlink already provides this name?
iscsi has not control over the block device naming and symlinks. You
would want to ask lkml.
It probably breaks everything that uses this block path directly to find
out the device it is pointing to.
I am not sure if that is a good idea. There is a doc that comes with the
kernel on how to write for sysfs. I attached it here. The iscsi sysfs
code does not follow this and that is why it got busted when sysfs
compat is disbaled in the kernel. I am replacing our sysfs code right
now though.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---
Rules on how to access information in the Linux kernel sysfs
The kernel-exported sysfs exports internal kernel implementation details
and depends on internal kernel structures and layout. It is agreed upon
by the kernel developers that the Linux kernel does not provide a stable
internal API. As sysfs is a direct export of kernel internal
structures, the sysfs interface cannot provide a stable interface either;
it may always change along with internal kernel changes.
To minimize the risk of breaking users of sysfs, which are in most cases
low-level userspace applications, with a new kernel release, the users
of sysfs must follow some rules to use an as-abstract-as-possible way to
access this filesystem. The current udev and HAL programs already
implement this and users are encouraged to plug, if possible, into the
abstractions these programs provide instead of accessing sysfs directly.
But if you really do want or need to access sysfs directly, please follow
the following rules and then your programs should work with future
versions of the sysfs interface.
- Do not use libsysfs
It makes assumptions about sysfs which are not true. Its API does not
offer any abstraction, it exposes all the kernel driver-core
implementation details in its own API. Therefore it is not better than
reading directories and opening the files yourself.
Also, it is not actively maintained, in the sense of reflecting the
current kernel development. The goal of providing a stable interface
to sysfs has failed; it causes more problems than it solves. It
violates many of the rules in this document.
- sysfs is always at /sys
Parsing /proc/mounts is a waste of time. Other mount points are a
system configuration bug you should not try to solve. For test cases,
possibly support a SYSFS_PATH environment variable to overwrite the
application's behavior, but never try to search for sysfs. Never try
to mount it, if you are not an early boot script.
- devices are only devices
There is no such thing like class-, bus-, physical devices,
interfaces, and such that you can rely on in userspace. Everything is
just simply a device. Class-, bus-, physical, ... types are just
kernel implementation details which should not be expected by
applications that look for devices in sysfs.
The properties of a device are:
o devpath (/devices/pci:00/:00:1d.1/usb2/2-2/2-2:1.0)
- identical to the DEVPATH value in the event sent from the kernel
at device creation and removal
- the unique key to the device at that point in time
- the kernel's path to the device directory without the leading
/sys, and always starting with with a slash
- all elements of a devpath must be real directories. Symlinks
pointing to /sys/devices must always be resolved to their real
target and the target path must be used to access the device.
That way the devpath to the device matches the devpath of the
kernel used at event time.
- using or exposing symlink values as elements in a devpath string
is a bug in the application
o kernel name (sda, tty, :00:1f.2, ...)
- a directory name, identical to the last element of the devpath
- applications need to handle spaces and characters like '!' in
the name
o subsystem (block, tty, pci, ...)
- simple string, never a path or a link
- retrieved by reading the subsystem-link and using only the
last element of the target path
o driver (tg3, ata_piix, uhci_hcd)
- a simple string, which may contain spaces, never a path or a
link
- it is retrieved by reading the driver-link and using only the
last element of the target path
- devices which do not have driver-link just do not have a
driver; copying the driver value in a child device context is a
bug in the application
