Scope and Using devices

[David Zeuthen]

Hi,

So we've discussed the scope of HAL the past couple of days and these
discussions have been great. Robert mentioned in a mail that the scope
of HAL is

 o  Device discovery, enumeration, so on
 o  No policy

I would add to this

 o  Merging of vital device information that cannot be probed or
    extracted from the hardware or a driver like e.g. this is a
    camera, a mp3 player, or this reader reads compact flash etc.

and this is basically what we got today. It's sweet too, if you look
at the work underway of integrating this in Nautilus and gnome-vfs -
it almost feels like Mac OS X. Joey's work on the wireless stuff is
great also. So, it's only device discovery so far, but it rocks since
the device list reflects what is plugged into the system at any point
in time. Much better than what we had before.

I'd argue that the level of information the HAL should export about
each device should be related to 

 o  What the device is and what it does
 o  How the device is configured

The first I take for granted we should export (includes 'this is a
camera', 'this reader reads compact flash' etc.), the latter is more
interesting. Examples of the latter in HAL today:

 o  We have a net.ethernet.link property that tracks whether your
    wired ethernet port is connected to another transciever

 o  Joe's wireless scanning stuff

 o  Whether a storage volume is mounted and where it is mounted

and I'd argue that these are all fair and square because this is
information that desktop environments deeply care about because policy
pieces at the application level can do interesting stuff that is
important to users. And without HAL, this information is just a pain
to retrieve, especially for a non-root processes.

Now, should we include stuff like this is the IPv4 address of the
networking device? Maybe, I'm not really sure, I tend to say no. Why?
Because if we do this, should we do the same for IPX (isn't this a
Novell protocol, btw?)? Or IPv6? 

The most important reason for not doing this is that there already is
a perfectly good API for this, like ifconfig(8) or some library, that
is well understood and already used in many applications. And it's oh
so easy to use this API given the HAL device, just read the property
net.device. Of course, the per-OS stuff will have be abstracted when
using the API. And there are practical problems when writing with this
API like permission problems and policy problems, more on that later.

And second, some device classes really deserve their own framework
like networking devices and my favourite example is still this

 http://freedesktop.org/pipermail/xdg/2003-September/002533.html

proposal by Sean.

To integrate HAL to fulfill the promise of "Making hardware just work"
we need to do so incrementally; the path must be evolutionary, free
software doesn't work in an revolutionary way. We need to build on top
on top of existing software, where applicable, and step by step
removing the crufts like the "Select device" boxes in various user
interfaces.

Of course, the utopian dream is to have a superb developer platform
for using devices such that application developers can say "I'd like
to interact with hardware of capability 'handheld_video_player' so I
just use libhandheldvideoplayer to push out the any video clip
supported by e.g. gstreamer to this device that may support only one
or two video formats". 

We'll get there, slowly, but surely. 

One of these days hopefully we'll get HAL integrated with libgphoto
and that would be great. Robert's libinput as posted on utopia-list is
another great example.

Now, on to using devices. Using devices have always been a goal of
the HAL project, but not a the daemon level. I had some wet dreams
early on providing D-BUS interfaces for everything (and bridging
them in-process):

 http://freedesktop.org/pipermail/dbus/2003-October/000530.html
 (look at the end of the mail)

Havoc pretty much shot that down 

 http://freedesktop.org/pipermail/dbus/2003-October/000534.html

So my position have since pretty much been leave that to libraries.

Now, granted, some aspects of using devices involves OS-dependent
things that may involve system-level policy and root-access and it
would be such a pain if desktop applications need to call stuff like
console-helper to get the job done. Like the whole thing that started
the thread with setting ESSID.

So, I still think we should stick with having things in libraries, and
I'm not really sure it's sane to rely on a set-property API at all
cf. my earlier comments regarding security and multiple things to
change at the same time. Further, it would really tie us down insofar
that the properties we would export would need to map one to one
to ioctl stuff. Second, it would be rather difficult for application
programmers to figure out whether a property can be set or not. 

Okay, so Owen raises a good point about us offering more interfaces,
yeah, well we would, but probably not a lot. Also, in a hopefully
not-so-far future people would use real object oriented languages so
they could do stuff like

 if (obj.isinstanceof(Net.Ethernet.80211)) {
     /* do stuff like set the ESSID */
     try {
         obj.set_80211_configuration(..);
     } catch (SomeHalException exp) {
         /* handle error */
     }
 }

or something..

So, for things that might involve OS-dependent use of devices, by
all means lets expose the /etc/hal/methods.d/<foo>/<bar> API I talked
about. That would be great for the wireless stuff as well. And I still
think it would be sane to export a method SetVolumeName on the
interface org.freedesktop.Hal.Device.Volume :-).

I hope this clarifies my position, and I don't really pretend this is
the best solution at all; afterall I only maintain this stuff - much
of the reason HAL is like it is today is because of discussions like
these so please feel free to disagree or propose an even better
roadmap.

Cheers,
David


_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal