Re: Blocks runtime in the kernel

On Tue, 28 Mar 2023 01:14:42 +0300
Konstantin Belousov <kostikbel@gmail.com> wrote:

> 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().

Thanks for all the feedback.  I ended up going roughly jhb@'s route,
but including an (optional) cleanup function, in case the netstack
needs to do some cleanup afterwards.  This went in e2427c6917.  I'm not
sure if cleanup is necessary, but in the case a stack might allocate
memory for the iterator, it's there (goal being to allow unmodified
drivers to work with different stacks).

On a side note, a friend of mine would love to see C++ in the kernel,
but that's a discussion for another day.

- Justin