Date: Mon, 7 Jan 2019 20:53:45 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Fabian Freyer <fabian.freyer@physik.tu-berlin.de> Cc: Christian Barthel <bch@online.de>, freebsd-jail@freebsd.org, stefan@gronke.net Subject: Re: kqueue(2) kevents for jails Message-ID: <20190107185345.GH2326@kib.kiev.ua> In-Reply-To: <5ca6662f-ec0d-a9a5-319f-af8b1fb011cc@physik.tu-berlin.de> References: <106dc2ec-9b92-6885-ca4c-8422e0aa061c@physik.tu-berlin.de> <87k1jkmja7.fsf@x230.onfire.org> <ae977530-0297-d404-f34d-90762bc7da7a@physik.tu-berlin.de> <20190104202910.GV2326@kib.kiev.ua> <5ca6662f-ec0d-a9a5-319f-af8b1fb011cc@physik.tu-berlin.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 04, 2019 at 10:22:07PM +0100, Fabian Freyer wrote: > > > On 1/4/19 9:29 PM, Konstantin Belousov wrote: > > On Fri, Jan 04, 2019 at 09:11:58PM +0100, Fabian Freyer wrote: > >> On 1/4/19 5:14 PM, Konstantin Belousov wrote: > >>> No, kevent(2) is not suitable mechanism to notify about jail state changes. > >>> If anything in the existing system can be reused for such notifications, > >>> it is devctl(4) notifications which are handled by devd(8). Look at the > >>> man pages and for existing notifications in kernel code, e.g. > >>> sys/kern/kern_conf.c notify*() for how devfs does it. > >> > >> Can any running binary subscribe to devd(8) events or does that require > >> a configuration change in /etc/devd.conf? > > > > Only one reader is supported, effectively. devctl(4) tries to limit opens > > naively. But then even if you have the file descriptor and fork or pass > > it over unix domain socket, single event can be only read by one reader. > > > > Ah, I see, thanks! Is there any other nice notification mechanism that a > process could 'subscribe' to to be notified of an event? devctl(4) is currently the best mechanism. Apparently there is a functionality in devd(8) which I was not aware of. In essence, it can operate as fan-out service, delivering kernel events to all clients connected to /var/run/devd.seqpacket.pipe socket. So despite /dev/devctl* not allowing multiple clients, you would make your service connect to devd(8) and get the events stream from there. > > I am still a bit confused as to why knotify would be such a bad fit, > maybe you could expand a bit on that? I have no idea what is knotify. > > > Not least because jail creation/destruction is relatively low frequency > > events with potentially rich secondary information that should be attached > > to them. Kevents are high-frequency, high-performance kind of events, > > Does this mean they cannot nicely be used for lower-frequency things? > I'm thinking of situations where jails may get spawned e.g. > per-network-request. They are not nice to be bolted on things which are not supposed to be performance-critical. Not least because _properly_ supporting kevents adds significant maintainance cost on the code. > > > and only naturally tied to file descriptors. > > according to kevent(2), > > EVFILT_PROC Takes the process ID to monitor as the identifier > > so there's also cases where it isn't tied to a file descriptor, but some > other descriptor (pid's don't seem to be too different to jid's?) Did you read what I wrote in previous message ? > > > There were lot of bugs in > > integration of kevents with e.g. processes notifications, and API is > > still somewhat racy > > Is this a kevents issue or an integration problem? It is architectural problem. > > In the end, might it be a good idea to add devctl(4) notifications as > well as kevent(2)?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190107185345.GH2326>