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 <ibid.ag@???> 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
::
Re: [DNG] [Dng] Hal and Vdev
