Le 19/03/2019 à 09:56, aitor_czr a écrit :
Hi Nick,
On 19/3/19 9:21, Dr. Nikolaus Klepp wrote:
...
for i in /sys/class/net/eth*; do
...
Thanks for your script! Interesting to know... With a short look, i
seems to read the value content in the /sys/class/eth0/carrier file,
set to "0" or "1".
Just a reminder that using symbolic links in /sys isn't robust, as
expained in
https://www.kernel.org/doc/html/v4.16/admin-guide/sysfs-rules.html
Here are two citations from this link. 1st citation:
/It is agreed upon by the kernel developers that the Linux kernel does
not provide a stable internal API. Therefore, there are aspects of the
sysfs interface that may not be stable across kernel releases./
/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./
I think we all agree to not follow this recommendation of linking
to libudev. 2nd citation:
/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./
There is at least one thing stable: the property of each devices
are represented by files in a subdirectory in the tree below
/sys/devices and this subdirectory is named after the device name, eg
/sys/devices/pci0000:00/0000:00:19.0/net/eth0
Therefore, the only robust method I have found to programatically
discover the device properties is to visit systematically all
directories below /sys/devices until I find the proper subdirectory.
My 1 cent.
Didier
_______________________________________________
Dng mailing list
[email protected]
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
