Re: Replaying event for a libudev monitor

[Marcel Holtmann <marcel@holtmann.org>]

Hi Kay,

> > so the enumeration API of libudev is pretty since, but when using a
> > monitor to get add/change/remove events anyway, it is kinda double work.
> >
> > So I have udev rules to select certain events to send to a specific
> > socket and that works great and truly simple with libudev. However when
> > the client starts up, it has to discover the initial state of these
> > events. I can use the enumeration part of libudev, but then I am putting
> > details into a rules file and others into the client.
> >
> > So what I like to have is a way to replay the events for that monitor
> > socket. Something similar to this:
> >
> >        ctx = udev_new();
> >        mon = udev_monitor_new_from_socket(ctx, "@socket");
> >        udev_monitor_enable_receiving(mon);
> >
> >        /* setup watch etc. */
> >
> >        udev_monitor_replay_events(mon);
> >
> > What do you think? Can we add something like this?
> 
> You want something like a "daemon coldplug"?
> 
> Something that would parse the rules and tries to match the devices,
> which matches the rule that sends the event? The rule parsingis
> currently not part of libudev. Matching devices might involve running
> programs from rules, so we should not do that in a single serializing
> process, as it might block for too long. We should also not use the
> daemon to trigger events, because global events would be send to all
> other listeners.
> 
> Care to explain your idea a bit more, I may miss something here?

I think you get it pretty much. You could describe it is as "daemon
coldplug" for events for a specific RUN=+"socket:*".

Something similar to what you have with "udevadm test" at the moment,
but with the limitation that only this one socket gets the events.

As mentioned before, the reason behind this is that without some kind of
support I have to put matching rules into a *.rules file for runtime
detection and another set of matching logic into the client using
libudev enumeration. I prefer to have both pieces in the *.rules files
since then it is easy changeable.

So I do see your point with the matching rules that run external
programs. I wasn't thinking about them since so far the matching rules
are kinda simple. I do wanna avoid to just send all udev events to the
monitor (like HAL and DeviceKit does) since that is just overhead and
re-implementing the matching code and scripts is just not a good idea.
The things that udev provides right now are perfect.

My current simple idea to solve this would be to add another
udev_ctrl_msg_type that libudev then can use to trigger this.

Looking at the code it seems that you identify the socket already using
udev_ctrl_new_from_socket() and so no need for an extra parameter to
this new command. Maybe UDEV_CTRL_REPLAY_EVENTS and then we wrap this
low-level command around udev_monitor_replay_events() for libudev. And
then udevd is responsible for the threading, invoking of programs and
making sure no other RUN+="socket:*" are executed.

Regards

Marcel