kqueue(2) kevents for jails

[Konstantin Belousov]

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)?