Scope and Using devices

[Joe Shaw]

Hi,

On Fri, 2004-05-28 at 13:42 +0200, David Zeuthen wrote:
> 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? 

I don't see any particularly strong reason not to include this (for all
of them), although the fact that the API is pretty simple and portable
makes it not nearly as important.

(And nobody uses IPX anymore, not even Novell. :)

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

If you're making a round trip to get the interface name, I don't see any
real reason why you wouldn't also just get the IP address, if you were
planning on displaying it.

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

Totally agree.  If you look at the gnome-netstatus applet in GNOME CVS
(http://cvs.gnome.org/viewcvs/gnome-netstatus/src/netstatus-sysdeps.c?view=markup) then you can see it's just begging for HAL.

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

Not to mention that even within Linux there can be different platforms
for doing something.  Take ALSA and OSS for example.  It seems very lame
to me as a library or application developer to be able to get
"sound.volume" from HAL but then have to use some system-dependent way
to set it.  Not to mention error prone.  And if I have to do this work
anyway, what's the real advantage of having an abstraction layer?

So if the primary scope of HAL is device discovery, that's fine and I'm
cool with that.  But if we're using it to get specific properties of
that hardware, like block volume labels or wireless settings, I think it
makes sense to also set them, or else it's not that useful to many
library and app developers.

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

The security model is one I don't have an answer for right now, short of
implementing our own, and I'm not real keen on that, obviously.

The ioctl stuff, I'm not totally sure what you mean by that.  Things has
been generally a 1:1 mapping, and hopefully anything that we'd expose as
settable would be pretty easily translatable to ioctls or whatever else
is used in setting.

As for the, uh, "settability", I suspect that'd be something that would
require examining the spec, as it would also for a lot of the properties
that are there today which don't make much sense.

> Okay, so Owen raises a good point about us offering more interfaces,
> yeah, well we would, but probably not a lot.

Yeah, and he also brings up a pretty good point about it not being
particularly future-proof, which is also an issue. :)

Joe


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