kobject-uevent

[Kay Sievers]

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

Sounds good, yes.

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

HAL will emit a "DeviceRemoved" event for the soundcard. That is the
right signal to watch, not the kernel module. Yeah, the soundcard
support is still to be done in HAL. :) 

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

You get a class device for the videodev which is represented as a HAL
device with "multimedia" properties. Applications interested in video
input devices should subscribe to this class of devices and never watch
kernel modules.

Kay

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