Proposed F19 Feature: systemd features

Stephen C. Tweedie sct at redhat.com
Mon Jan 28 15:41:57 UTC 2013


Hi,

On Mon, 2013-01-28 at 10:06 -0500, Stephen Gallagher wrote:
> On Mon 28 Jan 2013 08:49:39 AM EST, Tomáš Smetana wrote:
> > On Mon, 28 Jan 2013 07:41:38 -0500
> > Stephen Gallagher <sgallagh at redhat.com> wrote:
> >
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> On Sun 27 Jan 2013 08:54:49 AM EST, Jaroslav Reznik wrote:
> >>> Announcing various systemd features in one announcement, see
> >>> bellow:
> >>>
> >>
> >> <snip>
> >>
> >>> = Features/SystemdHardwareDatabase =
> >>> https://fedoraproject.org/wiki/Features/SystemdHardwareDatabase
> >>>
> >>> Feature owner(s): Kay Sievers <kay at redhat dot com>
> >>>
> >>> The udevd service has a long history of managing kernel devices.
> >>> Besides generating events when devices are discovered or removed it
> >>> maintains a dynamic, stateless database of all available devices
> >>> including meta data about them. With Fedora 19 we want to
> >>> substantially enhance the metadata that udev keeps for each device,
> >>> by augmenting it from a userspace database of non- essential
> >>> information, that is indexed by device identification data such as
> >>>  PCI/USB vendor/product IDs.
> >>>
> >>
> >> This to me looks like it would be an excellent data source for our
> >> hardware inventory provider. We should sync up with the systemd folks
> >> to identify the available D-BUS interfaces to query for this information.
> >
> > Looks interesting.  I'm not quite sure whether D-Bus is easier than
> > libpci/libusbx but if there would be also more "inventory" data available
> > from systemd then probably yes.
> >
> 
> I just had a discussion with Kay Sievers on IRC where he informed me
> that all of the information gathered in this way is queryable through
> libudev (accessing either the hardware directly or the database being
> populated by systemd).

Sounds good --- the more reuse of code to walk the low-level bus
information, the better.  Talking to udev rather than libpci or libusb*
directly sounds far preferable.

--Stephen




More information about the openlmi-devel mailing list