Hello, I'm new to this list, a bit curious about udev and the upper layers. I have some questions, not too dumb I wish.
----- re-expliciting to understand myself ----- ** What I want : ** I want the ability for a simple user to set ANY action automatically done according to device events ... with the "state-of-art" way to think the device events. ** Example : ** (http://archives.gentoo.org/gentoo-user/msg_a693a31dfbe5f8b5d4c3ed1c11dbe5ea.xml) "spawn a terminal in the mount-point when a specific mp3 player is plugged and mounted." For the "mount" part, udev works well for that. ** Questions / Ways to do : ** But how to get the user execute it's stuff. 1) have a system daemon which execute user's rules (with this specific user priviledges) 2) have a per-user listener which get informed (by IPC) about the event ** Guesses / Solutions to 1) : ** I first think about the 1) : I wrote a small uudevd.c (like user-udevd) but it appears that : - loading a set of rules isn't part of libudev so I would have to copy a subset of the udev rules parser (eg : remove SYMLINK as we are NOT root, that's why I put "subset" [rules set] in the subject) - getting informed about new event isn't much useful as we can't do anything useful at this level (I know the SERIAL_ID but can't mount) so... the user rules differ a bit from root's rules which are pure hardware ones. For a user, I need of course to know the LABEL or SERIAL_ID to perform my action, but also, if my mp3 player has been correctly mounted by the system udev rules and if I have the right to access it. Otherwise I thought about a ~/.udev/rules.d loaded by udev (or a udevcron {-l,-e} with a ~/.udevtab) I doubt about whether this idea is good|bad, I don't know why -it hasn't been done yet- ? (but anyway I would like to be able to do some actions as a user at this level even if a [[ -d $mountpoint ]] is mandatory) solution 2 to 1) : add the following key name : "USER" to execute PROGRAM or RUN as the given user -> seems totally dumb : set as root something for a specific user solution 3 to 1) = displace the question to 2) : give it to a system daemon by dbus : - then it broadcast to anyone so a per-user event system : - can't rely directly upon udev (not enough information / rights) - shouldn't [...] (not done) ** Guesses / Solutions to 2) : ** DBUS : the need of an IPC system <-> user (=> per-user daemon) System daemon, can be ringed by udev according to some events, ability for a user to run per-user dbus-listener of the system daemon... ----- Here come the choice ----- ... so I want a user-session configuration file to put, eg : <the event> <the script> <somes args> >From what I understand, there are : SYSTEM | USER shell hald | halevt & devkit-daemon | gcc "devkit_client_new(); switch (dict entry)" & If I just wanted to solve the problem I use one of the upper two. But about hal it aim to disappear (from what I understood) replaced by devkit. (it appears to be to "high-level" for me, I would prefer to listen the almost-raw udev event (for the moment at least)) As stragely as it can : halevt reports more event than devkit ... a simple manual umount (not really a hardware event) is reported by halevt (don't know where does it come from) But also : " +NOTE NOTE NOTE: This is probably the last release of DeviceKit. The + functionality of DeviceKit is going to be merged into the + udev-extras with the only changes being the D-Bus name + as well as the prefix for the GObject library and the + command line tool." So I installed udev 146 but I cannot find anything like that. *********** QUESTION ************** As devkit uses dbus it's aimed to be a per-user listener. Anyway it provides almost the same information (content / structure) than libudev (http://article.gmane.org/gmane.linux.hotplug.devel/13925) So I'm not far to think that the solution 1 to the way to do 1) is not as wrong as I though (user listener directly relying upon libudev or ... isn't devkit doing what would does a udevd taking into account per-user udev rules ?) What's the conceptual structure I'm looking for (<the event> previously written) ? AFTER the concretization of devices by major/minor/drivers/symlink) but BEFORE the [what I feel as a] restriction implied by hal (or is just the hal syntax the subject of a kind of freudian refusal ?) (and where to find devkit related stuff in the last releases of udev ?) Thanks for reading. Good day Raph _______________________________________________ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
