On Fri, 2009-01-02 at 15:04 +0100, Marcel Holtmann wrote: > 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. You mean the "trigger" not the "test", right? > 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. That sounds nice, sure. > 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. Maybe we could do something like: UDEV_CTRL_EVENT(socket-match, devpath, action) to inject events into the daemon. We probably do not want the sysfs crawling logic running in the daemon. The daemon would execute the single event, but ignore all RUN keys without a matching socket string. We may use the enumerator to pass all needed events to the daemon. One argument for udev_ctrl_send_event() is the match for the RUN keys specified in the rules, only matching RUN sockets would be executed. In many cases we need to limit the triggers to certain subsystems. Like you want to ignore the "block" subsystem, if you don't need it, with the possible 10.000+ block devices. :) In general I'm scared that people will use that and cause hundreds/thousands of processes/threads with every daemon that needs to initialize that way. It looks like the most correct solution from the API/config side, because you have only a single rule, that filters and sends events, where you hook your daemon code into. But on the other hand, it also sounds like a very wrong, and _very_ expensive way to do a "daemon initialization". People try to limit the current udev coldplug cost, and now we would introduce the same thing for every daemon. :) We may not want to provide such infrastructure, just imagine a system bootup where several daemons trigger all devices, with a process/thread for every device on the system. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
