Scope and Using devices

[David Zeuthen]

Hi,

On Fri, 2004-05-28 at 14:10 -0400, Joe Shaw wrote:
> 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.
> 

I think Owen has another good point in that IP is software. And if we
start putting all sorts of software properties onto devices it smells
like policy.

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

Heh, I recall a blog entry of yours mentioning IPX networks :-)

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

It would be cached anyway or read from a file once we save the HalDevice
objects to disk, but yeah, you're right.

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

Yeah

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

Well, HAL shouldn't care about sound,volume since that really a software
thing. What HAL should care about is the fact that some devices are
sound cards and then e.g. the sound server or the userspace parts of
ALSA or OSS could use HAL to enumerate the devices or be notified of new
hardware. Then with one simple patch (yeah right, like it's /that/
simple :-), all applications benefit from device notification etc. 

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

I fully agree. Really. I think where we might disagree is

1. What kind of properties should HAL expose. I say, let's keep to
hardware and the configuration of hardware. And thus I argue that
scanning for wireless networking is actually in the realm of hardware
configuration. Thus we should really provide a way to change that. Same
with volume labels. It's the right thing to do.

2. Whether the properties should be set via SetProperty or via an API. I
have argued for the latter but do note I'm cool with the former. I just
see some issues doing that.

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

Right.

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

Which is kind of moot as I replied as we want to freeze the interfaces
at some point. HAL lives very low down in the stack so ABI/API stability
will be insanely important.

Cheers,
David


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