:: Re: [DNG] [Dng] Hal and Vdev
Inizio della pagina
Delete this message
Reply to this message
Autore: Jude Nelson
Data:  
To: Isaac Dunham
CC: dng@lists.dyne.org, JeremyBekka C
Oggetto: Re: [DNG] [Dng] Hal and Vdev
Hi Isaac,

On Wed, Jun 17, 2015 at 12:49 AM, Isaac Dunham <ibid.ag@???> wrote:

> 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.
>


I already have that, then. I forked ata_id some time ago to create
stat_ata (installed to /lib/vdev/stat_ata), and vdevd's helper scripts
already use it to query (S)ATA disks to generate their persistent symlinks.

Thanks,
-Jude