-----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.
<snip>
= Features/SystemdResourceControl = https://fedoraproject.org/wiki/Features/SystemdResourceControl
Feature owner(s): Lennart Poettering <lennart at poettering dot net>
systemd already has support for assigning specific resources to system services using various configuration settings. With Fedora 19 we'd like to build on that, and add the ability for the admin to dynamically query the resource control parameters and change them at runtime.
This is definitely another thing to keep an eye on. This is exactly the sort of performance tweaking we will want to be able to accomplish from a central location, so we should very seriously consider how best we can control this via OpenLMI.
On Mon, 28 Jan 2013 07:41:38 -0500 Stephen Gallagher sgallagh@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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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@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).
(09:40:20 AM) sgallagh: kay: Is there a readily-available API doc around somewhere? (09:40:40 AM) kay: sgallagh: libudev provides the raw questy interface, yes. udev merges most of the data into its database. but a network scanner might want to resolve mac address OUI data for devices which are not local, so it has to query the db (09:41:00 AM) kay: sgallagh: http://www.freedesktop.org/software/systemd/libudev/libudev-udev-hwdb.html (09:41:27 AM) kay: sgallagh: that's the data so far: http://cgit.freedesktop.org/systemd/systemd/tree/hwdb (09:43:11 AM) kay: sgallagh: it's stored in a radix-tree like binary structure, which can be looked up by the user at basically "no cost". unlike the text file parsing was in the past ...
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@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
On Mon, 28 Jan 2013 15:41:57 +0000 "Stephen C. Tweedie" sct@redhat.com wrote:
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@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sun 27 Jan 2013 08:54:49 AM EST, Jaroslav Reznik wrote:
...
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.
My only concern is: would this be portable (to the older RHEL versions)? I'm not quite sure how important this fact is.
Regards,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue 29 Jan 2013 06:56:55 AM EST, Tomáš Smetana wrote:
On Mon, 28 Jan 2013 15:41:57 +0000 "Stephen C. Tweedie" sct@redhat.com wrote:
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@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sun 27 Jan 2013 08:54:49 AM EST, Jaroslav Reznik wrote:
...
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.
My only concern is: would this be portable (to the older RHEL versions)? I'm not quite sure how important this fact is.
No, it is almost certainly not backportable to non-systemd platforms. However we've stated in the past that our goal is not to be 100% compatible, but to support the largest feasible subset. Older systems, the output of lspci and friends is likely sufficient. But I think there's value in offering a richer set of data where possible.
openlmi-devel@lists.stg.fedorahosted.org
-
Stephen C. Tweedie -
Stephen Gallagher -
Tomáš Smetana