On Tue, Nov 24, 2015 at 10:37:08AM -0500, Anne Mulhern wrote: > > > > > ----- Original Message ----- > > From: "David Herrmann" <dh.herrm...@gmail.com> > > To: "Anne Mulhern" <amulh...@redhat.com> > > Cc: "systemd" <systemd-devel@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 <amulh...@redhat.com> wrote: > > >> From: "David Herrmann" <dh.herrm...@gmail.com> > > >> On Tue, Nov 17, 2015 at 11:57 PM, Anne Mulhern <amulh...@redhat.com> > > >> wrote: > > >> >> From: "David Herrmann" <dh.herrm...@gmail.com> > > >> >> On Mon, Nov 16, 2015 at 5:35 PM, Anne Mulhern <amulh...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
