From owner-freebsd-jail@freebsd.org Fri Jan 4 21:22:32 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 C6B12143A7CD for ; Fri, 4 Jan 2019 21:22:32 +0000 (UTC) (envelope-from fabian.freyer@physik.tu-berlin.de) Received: from mail.physik.tu-berlin.de (mail.physik-pool.tu-berlin.de [130.149.50.25]) (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 4B1B385698 for ; Fri, 4 Jan 2019 21:22:32 +0000 (UTC) (envelope-from fabian.freyer@physik.tu-berlin.de) Received: from [192.168.0.114] (firewall02.physik-pool.tu-berlin.de [130.149.50.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.physik.tu-berlin.de (Postfix) with ESMTPSA id 975BA61FA2; Fri, 4 Jan 2019 21:22:08 +0000 (UTC) Subject: Re: kqueue(2) kevents for jails To: Konstantin Belousov Cc: Christian Barthel , freebsd-jail@freebsd.org, stefan@gronke.net References: <106dc2ec-9b92-6885-ca4c-8422e0aa061c@physik.tu-berlin.de> <87k1jkmja7.fsf@x230.onfire.org> <20190104202910.GV2326@kib.kiev.ua> From: Fabian Freyer Message-ID: <5ca6662f-ec0d-a9a5-319f-af8b1fb011cc@physik.tu-berlin.de> Date: Fri, 4 Jan 2019 22:22:07 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190104202910.GV2326@kib.kiev.ua> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4B1B385698 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.992,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] 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: Fri, 04 Jan 2019 21:22:32 -0000 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? I am still a bit confused as to why knotify would be such a bad fit, maybe you could expand a bit on that? > 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. > 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?) > 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? In the end, might it be a good idea to add devctl(4) notifications as well as kevent(2)?