kobject-uevent

[Ikke]

On Mon, 2005-01-10 at 22:22 +0100, Kay Sievers wrote:
> 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.

Aha. So I should call some function from kobject_uevent_handler with all
information from the uevent, so in that function all types of uevents
can be handled (like mounted stuff -> disable /proc or mtab polling,...)

I'll do that tomorrow :-)


Next to this: how about "module loaded/unloaded" events? Now when my
alsa modules get unloaded, gnome-volume-control seems to crash, which
could be intercepted if the volume applet would know the module was
unloaded.
Other sample: gnomemeeting. When a V4L module is modprobed, it could add
a new video source (altough in this example a new HAL device will be
created too, I guess).

Thanks!
Ikke

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