Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 7 Sep 2025 03:26:49 +0300
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        James Gritton <jamie@freebsd.org>
Cc:        src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org
Subject:   Re: git: 851dc7f859c2 - main - jail: add jail descriptors
Message-ID:  <aLzRSTtSdzSJ5tOn@kib.kiev.ua>
In-Reply-To: <2f66c886ab44aea5ad2e57cc72c03e3f@freebsd.org>
References:  <202509042031.584KVpxY000408@gitrepo.freebsd.org> <aLokHDP-EMa1LR0D@kib.kiev.ua> <da6b56365c188ce55bb4e878636bc911@freebsd.org> <aLpxozYUfi_S-U7b@kib.kiev.ua> <2f66c886ab44aea5ad2e57cc72c03e3f@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 05, 2025 at 10:57:30AM -0700, James Gritton wrote:
> On 2025-09-04 22:14, Konstantin Belousov wrote:
> > BTW, you added some support for kqueue for jail events, but not to the
> > jail file descriptors.  This seems to be backward: if somebody wants to
> > monitor events for jails, then it is more reliable and straightforward
> > to do with the new jail fds rather than with ids.
> 
> It is at least incomplete, and not the state I want things to be at.
> There's a sticking point with jaildesc kqueue, so while I work that
> out I went with jid-baseds kqueue as a starter.
> 
> The trouble is child jails.  I took their handling from the existing
> child process handling, where I register a new kevent under the new
> jail's id.  But that's something I can't do with descriptors, since
> they have a process-specific identifier, the descriptor number.  The
> code that creates the new event, coming from the jail_set call that
> created a new jail, has access to the global descriptor (the struct
> file), but not to the process(es) that have it open, so I have no
> way of registering one or more events with that descriptor number.
> 
> One workaround is to have both jid- and jaildesc-based kevents, but
> both of them register a new jid-based kevent for a newly created child
> jail.  The caller may then get a descriptor with jail_get, and add a
> kevent for it and remove the old jid-based one.  This would work, but
> feels really klunky.
> 
> The other idea I've had is to register a temporary event, and then add
> code to kqueue_scan that converts that into a proper jaildesc event
> with the expected file descriptor number.  That would require either
> jaildesc-specific code in or around kqueue_scan, or adding another
> filterops function, neither of which is great.  Still, it seems the
> better solution.

This is not how the monitoring APIs work in general.  For instance,
when you register a listening socket in kqueue (or mark it for select or
poll), you do not get back a new connected file descriptor.  Kqueue only
provides a notification that new connection arrived, and then code
needs to accept it and get the file descriptor for new connection using
dedicated socket API.

> 
> With working jaildesc kevent support, the jid-based kevents would be
> unnecessary, so if I can get this done before 15 is released, they can
> go away.
> 
Then what is the point in adding something that app writers can't rely
upon, since this something is going away soon?

IMO, this whole commit series is not ready and the most lacking part is
the discussion of the architecture of the feature.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?aLzRSTtSdzSJ5tOn>