On Mon, 18.05.15 10:19, Richard Maw (richard....@codethink.co.uk) wrote: > On Sat, May 16, 2015 at 09:28:22PM +0000, Zbigniew Jędrzejewski-Szmek wrote: > > Why it the motivation? Patch description talks tabout passing the > > path/address in LISTEN_NAMES. Isn't this something that can be queried > > already? TODO talks about "identifiers". Is "identifier" the same thing, > > or did the TODO item about have some different meaning? > > I assumed that since the TODO came about at roughly the same time that systemd > gained the ability to hold onto fds for services while they restarted, that > this would be a way to identify the purpose of returned file descriptors > without having to store a mapping of the inode number and device number to fd > purpose into /run. > > The provided patch doesn't add a way to pass an identifier for a fd to systemd > though so if that were the motivation, then this patch wouldn't be > sufficient.
The TODO list item is purely about adding manual identifiers to fds, it's not about adding type information to them: the kernel already carries enough type information for us, the only problem is that sometimes the type alone is not enough, we want to properly give the fds a label. This has a number of usecases. One of them is this: logind wants to store fds referring to DRM or input devices in PID 1, so that it can be restarted at any time without losing access to the DRM/input devices it manages. Now, if you have multiple sessions that access the same devices, then each of the fds referring to these DRM/input device nodes look pretty much the same: their fstat() data is identical, their /proc/self/fd/<fd> symlink is the same, hence it's impossible to figure out which fd belongs to which session simply by looking at them with fstat() and /proc. Being able to attach a name to the fds is hence really useful. logind could use this to attach the session identifier to the fds, and would hence be able to safely map the fds back to their sessions after coming back from a restart... The names are useful in other cases too: if you have a daemon that listens on two protocols at the same time (let's say POP3 and IMAP4) on different ports, but not necessarily use the standard ports. hence you need a nice way during actviation to let your daemon know which one to use for which... (so far this was solved by having configuration also for the daemon that then maps the ports back to the protocol, but using ids for this is nicer, as it requires only one set of configuration). I hope that makes sense as rationale. The TODO list item is really about labelling fds, not about attaching type info to the fds. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
