[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1495553752.2751759.986007384.4E1A6A8B@webmail.messagingengine.com>
Date: Tue, 23 May 2017 11:35:52 -0400
From: Colin Walters <walters@...bum.org>
To: Jeff Layton <jlayton@...hat.com>,
Djalal Harouni <tixxdz@...il.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>
Cc: David Howells <dhowells@...hat.com>, trondmy@...marydata.com,
Miklos Szeredi <mszeredi@...hat.com>,
linux-nfs@...r.kernel.org,
"linux-kernel" <linux-kernel@...r.kernel.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
Linux FS Devel <linux-fsdevel@...r.kernel.org>,
"open list:CONTROL GROUP (CGROUP)" <cgroups@...r.kernel.org>
Subject: Re: [RFC][PATCH 0/9] Make containers kernel objects
On Tue, May 23, 2017, at 11:31 AM, Jeff Layton wrote:
>
> nfsdcltrack was originally nfsdcld, a long running daemon that used
> rpc_pipefs to talk to the kernel. That meant that you had to make sure
> it gets enabled by systemd (or sysvinit, etc). If it dies, then you also
> want to ensure that it gets restarted lest the kernel server hang,
> etc...
>
> It was pretty universally hated, as it was just one more daemon that you
> needed to run to work a proper nfs server. So, I was encouraged to
> switch it to a call_usermodehelper upcall and since then it has just
> worked, as long as the binary is installed.
Note that with the "read()/write() fd" model you don't need
a whole process just to do that...the functionality could be rolled into systemd
or equivalent easily enough.
> "You're doing it wrong. You just need to run all of these services as
> long-running daemons."
Also, I imagine we could figure out a clean model to do *activation*
from kernel -> userspace too. systemd's socket activation model
where pid 1 activates units on demand is quite nice and obviates
the need to configure things on in advance.
Powered by blists - more mailing lists