Scope and Using devices

[David Zeuthen]

On Tue, 2004-06-01 at 19:26, Joe Shaw wrote:
> On Fri, 2004-05-28 at 22:40 +0200, David Zeuthen wrote:
> > Robert wasn't wrong when he said you can be persuasive :-)
> 
> I think I may have completely flip-flopped on this.
> 

I think I mostly agree with you. 

I myself have trouble to articulate exactly what the scope is; when this
happen I normally just say "Oh, this whole HAL was all Havoc's idea
anyway" :-)

> Robert brought up a great point on Friday.  I don't remember if it was
> on-list or in person, but he asked, "If you didn't need to be root to do
> wireless scanning, would you have bothered adding it to HAL?"  The
> answer is definitely not.  If root weren't required, there is already a
> library there which would have gotten the job done just fine.  Apps
> could have used HAL and that library in tandem to change wireless
> settings, etc.
> 

Right.

> Based on your email I got a couple hackers together here at Ximian and
> tried to present the problem to them.  At first there was very much the
> feeling that HAL should try to abstract away as much access to the
> device as possible.  But as we talked about it a bit more, there was
> some retreat from this, but the one large issue that remained is access
> control.
> 

Exactly. It's very inconvenient when something requires root.

> The thing is, HAL will never be able to do device access as well or as
> flexibly as a library could.  "Do one thing and do it well", etc., etc.
> These libraries mostly already exist today: iwlib, libgphoto, etc.  In a
> lot of cases applications can use these along with HAL today, and
> hopefully these libraries will be adapted to use HAL intrinsically in
> the future.  Oh, and libraries can (and perhaps should) do policy,
> whereas HAL probably shouldn't.  It's having all that infrastructure in
> hald, resident in memory, probably isn't the best approach.
> 
> It doesn't make much sense to me to do things like bridge properties
> between HAL and CUPS when really the best API for this is (ahem, at
> least in theory) CUPS's own.
> 

Right. It wouldn't really be more convenient.

> So what we were thinking is that SetProperty would exist basically as it
> does today: a means for callouts to set properties as necessary, but
> that it'd have no real effect on the daemon's operation.  The properties
> would be basic details about the device: not settings.  Things like
> PCI/USB product, MAC address, network interfaces and device nodes,
> storage drive types, volume filesystem types would all still be there.
> Things like wireless properties wouldn't.  Things like volume labels and
> UUIDs fall into a gray area for me.  Maybe they should be omitted too.
> 

Yeah, these are a bit gray. I think it makes sense, though, to include
the aspects and details of a device that a user won't normally come
across when using the device. Especially things that may be used as a
basis for policy decision in the desktop environment (through D-BUS) and
core OS bits (through callouts). Such as whether the networking link is
up or down. And what kind of optical drive is installed and what is the
kind of the disc. And maybe even what wireless networks are available.

In a way, it can never be black and white. You argue that the
application or library can figure out everything themselves, and yeah
that's true. So why use something like HAL except that it does device
enumeration; the live device list. The application may even do this
themselves by looking at sysfs or the equivalent on a BSD flavor. It
might have to poll, but yeah it can do it. And it would be party time in
#ifdef land :-)

Well, the app should use HAL because it's convenient. 

Likewise when it comes to what properties are available. Convenience. It
would be sad if Mozilla or Konqueror would have to read the networking
devices' mii registers and listen the netlink socket on Linux just to
see if there is a connection available. It's simply not convenient.

So.. Abstractions are generally no silver bullets; it's something to
make the programmers on top get their job done faster. You could do
Evolution in x86 assembly, but it's just not convenient or easily done.
It's much easier to build on top of abstractions. Like Bonobo, gobject
and all that stuff.

And yeah, I still think it makes sense to provide writable properties
(one way or the other). Why? Because it's convenient. With this it
becomes a matter of triviality to write desktop policy engines. If you
don't have this it's just difficult and will result in #ifdef hell and
then it just doesn't happen. Or when it happens you have a "Select
device file" cruft in the user interface and that is just evil.

And HAL does one thing that we yet have to start to utilize: It allows
the programmer to think in higher level concepts like "capabilities".
Thing is there is different devices that do the same thing but how a
UNIX-like OS handles it is very different from device to device. Like
cameras - an application should never has to worry whether the driver is
a userspace libgphoto2 driver, a kernel driver or the usb-storage
driver. So HAL matches the device and we someone writes a library to
handle this capability. Of course, any application could do this, but
it's just not convenient.

> The core problem of access control still exists, but really that problem
> exists no matter what.  If we want to do setting, we can probably either
> implement our own (I've done it for Red Carpet, so I'm starting to get
> good at it. ;) or reuse dbus's.  But I'd rather see it fixed somehow in
> the operating system, maybe using POSIX capabilities.  But I hope that
> Robert will be able to answer more to that than I could. :)
> 

Yay, it would be nice if a user could be granted access to e.g. a
network device.

Thanks,
David



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