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

Greg KH gregkh at linuxfoundation.org
Tue Nov 24 12:15:21 PST 2015


On Tue, Nov 24, 2015 at 12:37:46PM -0500, Anne Mulhern wrote:
> 
> ----- Original Message -----
> > From: "Greg KH" <gregkh at linuxfoundation.org>
> > To: "Anne Mulhern" <amulhern at redhat.com>
> > Cc: "David Herrmann" <dh.herrmann at gmail.com>, "systemd" <systemd-devel at lists.freedesktop.org>
> > Sent: Tuesday, November 24, 2015 11:42:21 AM
> > Subject: Re: [systemd-devel] libudev: subdirectories in sysfs (what does "available" mean?)
> > 
> > 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
> > 
> 
> It's a bit bare, let me know if you'ld like me to add a few options.
> 
> [mulhern-journal at megadeth pyudev]$ find /sys/devices/virtual/block/dm-32
> /sys/devices/virtual/block/dm-32
> /sys/devices/virtual/block/dm-32/dm
> /sys/devices/virtual/block/dm-32/dm/name
> /sys/devices/virtual/block/dm-32/dm/uuid
> /sys/devices/virtual/block/dm-32/dm/rq_based_seq_io_merge_deadline
> /sys/devices/virtual/block/dm-32/dm/use_blk_mq
> /sys/devices/virtual/block/dm-32/dm/suspended

The issue here is that the dm core is not using a 'struct device' so
this isn't a "real" attribute hanging off of the dm-32 block device, but
rather an "unknown" kobject that userspace knows nothing at all about.
I thought I had warned the dm developers that this would happen, but it
looks like no one ever changed the code ;(

> /sys/devices/virtual/block/dm-32/ro
> /sys/devices/virtual/block/dm-32/bdi

That's not a subdir, but an attribute of the dm-32 block device, so yes,
udev will see it just fine.

So this is a kernel issue, not a libudev issue, please go pester the dm
developers to resolve this if you wish to be able to see the attributes
"properly".  But odds are, this isn't going to be able to be changed due
to the custom dm tools that are probably expecting this type of
structure.

Which goes back to the question, "why do you want to see dm attributes
in a program?"  Shouldn't the dm tools provide you all of the
information you need that is exported in these sysfs files?

thanks,

greg k-h


More information about the systemd-devel mailing list