[systemd-devel] libudev: subdirectories in sysfs (what does "available" mean?)

[David Herrmann]

Hi

On Tue, Nov 24, 2015 at 4:37 PM, Anne Mulhern <amulhern at redhat.com> wrote:
>> From: "David Herrmann" <dh.herrmann at gmail.com>
>> On Tue, Nov 24, 2015 at 3:54 PM, Anne Mulhern <amulhern at redhat.com> wrote:
>> >> From: "David Herrmann" <dh.herrmann at gmail.com>
>> >> On Tue, Nov 17, 2015 at 11:57 PM, Anne Mulhern <amulhern at redhat.com>
>> >> wrote:
>> >> >> From: "David Herrmann" <dh.herrmann at gmail.com>
>> >> >> On Mon, Nov 16, 2015 at 5:35 PM, Anne Mulhern <amulhern at redhat.com>
>> >> >> wrote:
>> >> >> > libudev has some cooperating procedures that return the keys for a
>> >> >> > bunch
>> >> >> > of
>> >> >> > sysfs attributes for a given device.
>> >> >> >
>> >> >> > These attributes all correspond to files that are stored in the sysfs
>> >> >> > device directory.
>> >> >> >
>> >> >> > In the same directory there are sometimes subdirectories, that
>> >> >> > themselves
>> >> >> > contain files
>> >> >> > with information about their corresponding attribute. The dm
>> >> >> > directory
>> >> >> > is
>> >> >> > one obvious
>> >> >> > example.
>> >> >> >
>> >> >> > Are their any plans for libudev to add an ability to get the values
>> >> >> > from
>> >> >> > these subdirectories
>> >> >> > as some kind of attributes?
>> >> >> >
>> >> >> > If no, why?
>> >> >>
>> >> >> sd_device_get_sysattr_value(device, "foo/bar/baz", &value);
>> >> >>
>> >> >> This should work fine (or its udev_device_* equivalent).
>> >> >>
>> >> >> Btw., I recommend just using readdir(), open(), read(), and write().
>> >> >> sysfs is a filesystem, no reason to wrap all those commands.
>> >> >
>> >> > Thanks, I'm asking this more as the pyudev maintainer than as someone
>> >> > who actually wants these values.
>> >> >
>> >> > The funny thing is, I recently found out that the list obtained by
>> >> > udev_device_get_sysattr_list_entry () and friends contains so
>> >> > called "available" keys, but when those get passed to
>> >> > udev_device_get_sysattr_value () the result might be NULL.
>> >> > That makes sense in the sense that they might represent files
>> >> > that are unreadable.
>> >> >
>> >> > Now I find out that I can make up keys not in the results of
>> >> > udev_device_get_sysattr_list_entry () and pass those to
>> >> > udev_device_get_sysattr_value() and get a non-null result.
>> >> >
>> >> > So, what does "available" mean? Do these sysattr_list_entry()
>> >> > methods give any useful information?
>> >>
>> >> "available" probably means attributes which are direct descendants of
>> >> the device. That is, sysattr_list_entry() only lists such direct
>> >> descendants, while sysattr_value() allows you to query anything (you
>> >> probably can even pass "foo/../../bar/baz").
>> >>
>> >> Thanks
>> >> David
>> >>
>> >
>> > I think it's yet more complicated than that. For example,
>> > 'dm' (for device mapper) is not in the list of available
>> > attributes, but 'dm/name' is certainly an attribute that
>> > can be read by sysattr_value().
>>
>> 'dm' is not an attribute, so it will never be listed as available
>> attribute. Directories are never treated as attributes.
>>
>> Thanks
>> David
>>
>
> But "bdi" is listed as an attribute, and is a directory.

Weird. Tom, any comments?