From owner-freebsd-jail@freebsd.org Mon Jan 7 18:53:55 2019 Return-Path: Delivered-To: freebsd-jail@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 90FD4149C04A for ; Mon, 7 Jan 2019 18:53:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F3D1B73844 for ; Mon, 7 Jan 2019 18:53:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x07IrlpS099983 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 7 Jan 2019 20:53:50 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x07IrlpS099983 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x07IrjZW099982; Mon, 7 Jan 2019 20:53:45 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 7 Jan 2019 20:53:45 +0200 From: Konstantin Belousov To: Fabian Freyer Cc: Christian Barthel , freebsd-jail@freebsd.org, stefan@gronke.net Subject: Re: kqueue(2) kevents for jails Message-ID: <20190107185345.GH2326@kib.kiev.ua> References: <106dc2ec-9b92-6885-ca4c-8422e0aa061c@physik.tu-berlin.de> <87k1jkmja7.fsf@x230.onfire.org> <20190104202910.GV2326@kib.kiev.ua> <5ca6662f-ec0d-a9a5-319f-af8b1fb011cc@physik.tu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5ca6662f-ec0d-a9a5-319f-af8b1fb011cc@physik.tu-berlin.de> User-Agent: Mutt/1.11.1 (2018-12-01) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 18:53:55 -0000 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)?