On Tue, Jun 16, 2015 at 02:55:09PM -0400, Jude Nelson wrote: > Hi Isaac, > > On Mon, Jun 15, 2015 at 11:40 PM, Isaac Dunham <[email protected]> wrote: > > I've looked at https://github.com/cshorler/hal-flash, and here's what > > I can make out: > > - This version uses dbus to connect to udisks2 for everything it > > doesn't stub out. I guess glib is used extensively. > > - Answers the following "property strings" for devices in > > libhal_device_get_property_string(): > > system.hardware.serial, storage.bus, storage.serial > > In libhal_device_get_property_uint64(), only storage.size is answered. > > In libhal_manager_find_device_string_match(), a query about > > key "storage.drive_type", value "disk", returns a list of hard drives. > > storage.bus seems to be more-or-less "ata", NULL, or ... > > something else, I don't know what. > > I'm not sure if storage.size is free space or total size, but it's > > an unsigned 64-bit value. > > > > The system serial numbers are stored in > > /sys/devices/virtual/dmi/id/*_serial > > but are chmod 0400 (readable only to root). > > > > libhal_device_get_property_{int,double}() are stubs. > > > > Very interesting. I'm currently in the process of getting vdevd to parse > the udev hardware database and generate /run/udev, so we should soon have > the necessary machinery to define an action that makes vdevd write those > fields somewhere where a stub libhal library can find them. I'll look more > into this, if I can figure out the exact fields the stub libhal will need > (it seems that they all come from sysfs?).
storage.serial won't, as far as I can tell; it comes from ata_id or the equivalent tool. HTH, Isaac Dunham _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
