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

[Greg KH]

On Tue, Nov 24, 2015 at 10:37:08AM -0500, Anne Mulhern wrote:
> 
> 
> 
> 
> ----- Original Message -----
> > From: "David Herrmann" <dh.herrmann at gmail.com>
> > To: "Anne Mulhern" <amulhern at redhat.com>
> > Cc: "systemd" <systemd-devel at lists.freedesktop.org>
> > Sent: Tuesday, November 24, 2015 10:15:05 AM
> > Subject: Re: [systemd-devel] libudev: subdirectories in sysfs (what does "available" mean?)
> > 
> > Hi
> > 
> > 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.

Can you provide a "full" path here that you are looking at (or the
output of 'tree' or 'find' on the device), so that I can try to figure
this out?

Odds are, dm is doing something "odd"...

thanks,

greg k-h