Plans for hal 0.5.x

[David Zeuthen]

On Mon, 2004-12-13 at 16:29 +0100, Kay Sievers wrote:
> > Whether udevd should talk to hald directly (having only one socket
> > connection to maintain order) or through an intermediate (e.g. D-BUS
> > signals) is an open question. Problem with the former case is that hald
> > goes into state D then udevd could also be screwed. I'm sure Kay can
> > comment here. The latter case give other nice things such as udevd
> > owning D-BUS service org.kernel.udev with interfaces to provide udevinfo
> > functionality. Dunno..
> 
> As said earlier, I'm not for getting something that complicated into
> udevd. udevd is damn stupid (for good reason) at the moment and does not
> know anything about devices, device nodes, sysfs, udev actions. If we
> teach udevd to get the data from the spawned udev process we need to
> read it from a file descriptor or similar and we need to talk to (from
> udev's view) untrusted software which is not the right thing from my
> point of view for that system critical software.
> 

Agreed.

> I'm all for keeping the layered architecture and the "low level" clean.
> We should not touch basic hotplug (what udev is in that case) with D-BUS
> and friends as there are a lot of good reasons people don't want that.
> 
> I serialized the whole event stream for that reason including the
> physical device:
>   you get /devices/* -> /block/sda -> /block/sda/sda1
>
> It doesn't matter how long each event takes, it will always be this
> order!
> 
> It is the default behavior of udev/udevd, no configure or compile time
> option, which is nice. If someone has an example, why the simple
> serialization doesn't work I will try to solve that. Promised! :)
> 

Cool, however if we use dev.d to tell hald, won't there be a race
between multiple hal.dev copies? E.g. we'd have to reorder in hald
anyway?

Cheers,
David


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