From: Lennart Poettering <lennart@poettering.net>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH] rpcbind: add support for systemd socket activation
Date: Fri, 23 Jul 2010 18:27:47 +0200 [thread overview]
Message-ID: <20100723162746.GA4509@tango.0pointer.de> (raw)
In-Reply-To: <4C49B1AD.3060302@oracle.com>
On Fri, 23.07.10 11:13, Chuck Lever (chuck.lever@oracle.com) 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.
next prev parent reply other threads:[~2010-07-23 16:28 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-19 2:19 [PATCH] rpcbind: add support for systemd socket activation Lennart Poettering
2010-07-21 17:56 ` Chuck Lever
2010-07-21 21:56 ` Lennart Poettering
2010-07-23 15:13 ` Chuck Lever
2010-07-23 16:27 ` Lennart Poettering [this message]
-- strict thread matches above, loose matches on Subject: below --
2011-12-19 23:42 [PATCH v2] " Cristian Rodriguez
2011-12-23 1:05 ` [PATCH] " Tom Gundersen
2011-12-23 1:34 ` Cristian Rodríguez
2011-12-23 2:40 ` Jim Rees
2012-02-01 11:47 ` Tom Gundersen
2012-02-01 15:32 ` Chuck Lever
2012-02-01 16:37 ` Tom Gundersen
2012-02-01 18:16 ` Chuck Lever
2012-02-01 19:48 ` Tom Gundersen
2012-02-01 21:45 ` Lennart Poettering
2012-02-01 22:03 ` Chuck Lever
2012-02-01 22:30 ` Lennart Poettering
2012-02-03 17:03 ` Chuck Lever
2012-02-01 19:59 ` Chuck Lever
2014-11-21 16:43 [PATCH] rpcbind: " Steve Dickson
2014-11-21 16:43 ` [PATCH] rpcbind: add support for " Steve Dickson
2014-11-25 17:05 [PATCH] rpcbind: systemd socket activation (v2) Steve Dickson
2014-11-25 17:05 ` [PATCH] rpcbind: add support for systemd socket activation Steve Dickson
2014-11-26 12:48 ` Steve Dickson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100723162746.GA4509@tango.0pointer.de \
--to=lennart@poettering.net \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).