kobject-uevent

Kay Sievers kay.sievers at vrfy.org
Mon Jan 10 13:22:52 PST 2005


On Mon, 2005-01-10 at 21:31 +0100, Ikke wrote:
> This is what I get in dbus-monitor now:
> 
> signal interface=org.kernel.KobjectUevent; member=KobjectUevent;
> sender=:1.98
> string:ACTION=add
> string:DEVPATH=/module/ext2
> string:SUBSYSTEM=module
> string:SEQNUM=1182
> signal interface=org.kernel.KobjectUevent; member=KobjectUevent;
> sender=:1.98

Why do you want to send all the raw events from hal to D-BUS? We should
not do that for the same reason I mentioned in the D-BUS case. These
events are not generally useful without a "real" context.

The goal of hal is to provide a unified interface for the various event
sources. Think of the netlink socket for the network layer. We get the
interesting messages for the network interface from there and change the
corresponding property on the hal-device-object which will emit a signal
to the subscribed application. Or we poll /proc/mounts and do the same
for the block devices.
No application should care about the source of this information. Hal
should generate sane and meaningful events with the proper context and
not act as an event proxy.

I think we should start with interpreting the useful messages and just
emit signals for an existing hal object like the mentioned mount/umount
messages for block devices. This way we get a real user for the messages
and we can go ahead adding more events to the kernel or add more device
representations to hal if needed.

The payload in the uevent message happens only for hotplug events. We
already get a saner version of the hotplug events on another socket. I
think you can just ignore the hotplug events and every possible payload.
No other kind message will have a payload, the uevent is just a sysfs
state change notification that is used to prevent polling.

> Please comment on it: bad coding style, missing error checking,
> whatever, but don't be too hard, I'm no elite hacker like some of you
> guys :-) I'm learning.

Don't be too deliberate. :) We're all still learning. That's the way it
works...

Kay

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



More information about the Hal mailing list