Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 28 Mar 2023 01:14:42 +0300
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        John Baldwin <jhb@freebsd.org>
Cc:        Brooks Davis <brooks@freebsd.org>, Justin Hibbits <jhibbits@freebsd.org>, freebsd-arch@freebsd.org
Subject:   Re: Blocks runtime in the kernel
Message-ID:  <ZCIVUtAyN9tu_mb2@kib.kiev.ua>
In-Reply-To: <0f19b708-c167-b05e-1b0d-e4c1029a50c4@FreeBSD.org>
References:  <20230316100611.4892008c@gonegalt.net> <ZBSshsmKIo6VirT/@spindle.one-eyed-alien.net> <0f19b708-c167-b05e-1b0d-e4c1029a50c4@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 27, 2023 at 12:11:03PM -0700, John Baldwin wrote:
> On 3/17/23 11:08 AM, Brooks Davis wrote:
> > On Thu, Mar 16, 2023 at 10:06:11AM -0400, Justin Hibbits wrote:
> > > Most probably know I've been working on the IfAPI conversion of all
> > > network drivers in order to hide the contents of `struct ifnet`.  I'm
> > > pretty much done with the development, and it's all in review.
> > > However, there's one bit that I've thought is very clunky since I added
> > > it, the if_foreach() iterator function, which iterates over all
> > > interfaces in the current VNET, and calls a callback to operate on each
> > > interface.  I've noticed that oftentimes I end up with a 2 line
> > > callback, which just calls if_foreach_addr_type(), so I end up with
> > > just trivial callback functions, which seems like a waste.
> > > 
> > > All that backstory to say, would it be beneficial to anyone else to
> > > add a (very basic) blocks runtime to the kernel for doing things like
> > > this?  The rough change to the IfAPI becomes:
> > > 
> > > int if_foreach_b(int (^)(if_t));
> > > 
> > > __block int foo = 0;
> > > 
> > > if_foreach_b(^(if_t ifp) {
> > >    if (if_getlinkstate(ifp) == LINK_STATE_UP)
> > >      foo++;
> > > });
> > > 
> > > The same could be done for other *_foreach KPIs as well, if this proves
> > > out.  I think I could have something working in the next several days.
> > > 
> > > The only technical snag I see with this would be other compilers.  I'm
> > > not sure if GCC still supports blocks, it did at one point.
> > 
> > I think two things make this a non-starter.  First, GCC doesn't support
> > this feature and I don't think we want to lose that for the reasons
> > Warner outlines elsewhere.  Second, it seems moderately likely that C2Y
> > will include lambdas in some form which fills the same niche.  This
> > will further reduce the likelihood of blocks support being widespread
> > (already extremely unlikely).  At this point I think we just need to
> > live with the clunky syntax. :(
> 
> Alternatively one could use C++.  I think that would be an easier sell
> than Blocks TBH.  It's not hard to write the little bits you would need
> to let you use a ranged-for for this (which I find more readable than the
> lambda approach anyway).
> 
> If you don't need to perform cleanup actions when terminating an iteration
> you could also provide helper functions that let you implement a
> IF_FOREACH() wrapper macro that would function similar to TAILQ_FOREACH().
> You would just need 'if_first()' and 'if_next()' helpers.

You might also take a look at the design of MNT_VNODE_FOREACH().



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