Plans for hal 0.5.x

[Kay Sievers]

On Mon, 2004-12-13 at 10:07 -0500, David Zeuthen wrote:
> > Second, with the migration from the old hotplug to the newer
> > udevd/udevsend architecture should finally help to get rid of the
> > sequence sorting and many deadlocks as well.

Nice, I really like to see progress in this area.

> That's right - I had some discussions with Kay about this and in my view
> it looks like udevd should tell hald about hotplug events; we need to do
> it from udevd because the spawned dev.d hal.dev programs may race
> against each other and come out of sequence. 

No, all events of one sequence are serialized. Only after the parent has
exited (all scripts are run) the child is executed.

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

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

Thanks,
Kay

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