:: Re: [DNG] an alternative to poetter…
Page principale
Supprimer ce message
Répondre à ce message
Auteur: aitor_czr
Date:  
À: dng
Sujet: Re: [DNG] an alternative to poettering's ifplugd
Hi Didier,

On 19/3/19 12:39, Didier Kryn wrote:
> 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



Thanks a lot for the info !!

Aitor.