On Fri, 23.07.10 11:13, Chuck Lever (chuck.lever@xxxxxxxxxx) wrote: > >But for now, if people just add this tiny bit of code to their sources > >this will be a feature that finds it way silently into the various > >packages without requiring any new dependencies, and people will hence > >have little reason to disable it. > > The complexity or size of the systemd code is not the issue, it is > how it will be maintained going forward. Especially since these are > all system daemons, you know that there will be security bug fixes. In code that simply parses two environment variables with strtol(), how likely is it to encounter a security issue in this? > The least you could do is provide both the raw source files and a > library implementation, and let daemon maintainers choose which they > prefer. The best solution would provide a clean versioned C > language API via a shared library Hmm, providing both is indeed an idea. However, we currently hide the symbols sd-daemon.[ch] exports when linking for good reasons. Now, if we supported both an .so and the drop-in code, then we'd have the same symbols once exported and once not. That's a weird kind of namespace clash... But anyway, we'll think about this and most likely add this sooner or later. However, if possible I'd very muhc prefer to use the drop-in code for now, if that's ok? I promise I'll prepare the patch that moves rpcbind to the the .so API as soon as we provide that ;-). > Do you have some picture of systemd adoption outside of Fedora? All bigger distributions have it (with one exception, see below). Some smaller distros made it the default already. Some folks at Suse are working on making it the default in their next release. Meego has folks working on something like this too. So basically, everybody who could adopt it has it at least packaged or is already on the path to making it the default -- with one exception: Ubuntu. The Upstart developer works for Canonical, so go figure. He was vaguely interested in adopting socket-based activation in Upstart too, but so far nothing has shown up. We have discussed with him whether he then would be willing to adopt the same interface systemd uses for socket activation. This petered out without result, but given that the interface we came up with is really trivial and we tried our best to keep this independent of systemd and already supported in quite a number of software our hope is that eventually he'll adopt this scheme too. Lennart -- Lennart Poettering - Red Hat, Inc. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
