:: Re: [DNG] [Dng] Hal and Vdev
Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Jude Nelson
Ημερομηνία:  
Προς: Isaac Dunham
Υ/ο: dng@lists.dyne.org, JeremyBekka C
Αντικείμενο: Re: [DNG] [Dng] Hal and Vdev
Hi Isaac,

On Mon, Jun 15, 2015 at 11:40 PM, Isaac Dunham <ibid.ag@???> wrote:

> On Mon, Jun 15, 2015 at 08:18:18PM -0400, JeremyBekka C wrote:
> > > Hi Jeremy,
> >
> > > I have a question about the deprecated program hal. We like to stream
> > > videos from Amazon.com but we need hal installed in order to make it
> work.
> > > The Hal Debian wiki says that it is being deprecated and it is being
> > > replaced by udev (https://wiki.debian.org/hal). Since vdev is being
> > > written to replace udev, are there any plans to incorperate hal's
> functions
> > > into vdev or keep maintaining it seperaratly?
> > >
> >
> > Do you know what specific functions of hal you need? Hal's functionality
> > got split between udisks/udisks2, upower, and udev some time ago. Things
> > like device plug state, device properties, and device capabilities are
> now
> > tracked by udev (in /run/udev) and accessed by libudev, for example. My
> > goal for vdev is to be compatible with udev, so if you can use udev
> today,
> > you should be able to use vdev when it's ready.
> >
> > Thanks,
> > Jude
>
> Hal is used "for DRM", which in the context of Flash and the period
> of development almost certainly is "Digital 'Rights' Management".
> I would presume from the fact that one can load the flashplayer
> without it that the library is dlopen'd.
>
> 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?).

Thanks,
Jude