From nobody Mon Mar 27 22:14:42 2023 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PlnDc4vM2z428wn for ; Mon, 27 Mar 2023 22:14:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PlnDc1dHnz3v1r; Mon, 27 Mar 2023 22:14:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.17.1/8.17.1) with ESMTPS id 32RMEh9k077047 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 28 Mar 2023 01:14:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 32RMEh9k077047 Received: (from kostik@localhost) by tom.home (8.17.1/8.17.1/Submit) id 32RMEgIg077045; Tue, 28 Mar 2023 01:14:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 28 Mar 2023 01:14:42 +0300 From: Konstantin Belousov To: John Baldwin Cc: Brooks Davis , Justin Hibbits , freebsd-arch@freebsd.org Subject: Re: Blocks runtime in the kernel Message-ID: References: <20230316100611.4892008c@gonegalt.net> <0f19b708-c167-b05e-1b0d-e4c1029a50c4@FreeBSD.org> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0f19b708-c167-b05e-1b0d-e4c1029a50c4@FreeBSD.org> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Rspamd-Queue-Id: 4PlnDc1dHnz3v1r X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N 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().