From nobody Mon Mar 27 19:11:03 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 4Plj8T6kFBz41wsL for ; Mon, 27 Mar 2023 19:11:05 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Plj8T6J8bz3ChZ; Mon, 27 Mar 2023 19:11:05 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1679944265; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=raC/X5aG8mKAxaSNc52OG8dYyMEw4dwWZGreExS47e0=; b=xLi9EJna9U1YUCMimn9Vd3V/AjI62aqk3rrE9BAyFanQf3fs3/NhH6LOSKBbEWZs6r4MdY /VIGCZV4HxX1r2eqP3lf6cw0qL2hgKkgBDigE0tZ9WOxuvedOzF2e1XHSjn9gC9Qv79ehn Z03ViaokQBzkjvOFCjcxfN++ulL2Jeh5GZttwfbojyj0YCn8Q+ZXHCD5Y7b8ZeC4uRcnUu FvevlWkCYaPVxu2GNCAEQTKri8OkOi/97R8z8f0oovZl0LPcfXgZiOP0Mn82jv5wqUyVgE tctwpfrfI9+6KSp0cYW281Qew112aK6/cSGG8OQ/vYVHeJguYIotmJc0D+bThA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1679944265; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=raC/X5aG8mKAxaSNc52OG8dYyMEw4dwWZGreExS47e0=; b=Ry87vtr5+IhtHkGfn358KnTzbqfL4Mh9WcF/E1Y9Mg37Gh3l/TRo6vXEA3reRmXaTlZlnI k38d3QU2cyReollbbttlV5ugKDua2OBHiNjQ/perRuQwNm34KELxaJ0Fomi1I0rCw3JyHp C1RCCu7q+zymRgQaPDgPu1WrO3fW9xl0XOVL6RKPOq36ZrGwKu+/BG/MgGqhOUmLrN+jNz EathGRpBYzh/Hk6aat+mq4yfPV7tE6rVrdy43FClgt4Wx31fX5HO77euf5je0gHsxNlcbk PseFw8NWBm7Di/iLOf8TqFKmgyCQ+B9rSVFCGSuHpjEZAUydmJUH+5c77wiSYQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1679944265; a=rsa-sha256; cv=none; b=nYh0yludz2991naXSZ5DnDo6b4RNCu1b5Vn1dWj5isoHZyag5Qgid69zGmUppTfRM4HZDy YVNDlmdRT9gsxqY3RaWQ8cs5oBgwfGS/4pxwjPDwHaKPQyOWqLqXFvsUtVE8Ktf9ohIN0J 21CGFw1IjS5icRnIUh5sCnv5JkGyq27MCOrSRg54SlbycONXxEV7fSJkCy0ZvQfCv7GQkq FQf1ES3o2/YhhdPCrRbyuAPJeI5aGB4ULjrc/5OCop44uaisZHYtvXg4u0ooIrSvwfjVxL st2Iph3Uio4ltElZC88HCEJWp6s8cFSOuBti2G/AXI/JaifB6JMKAex07HRceg== Received: from [IPV6:2601:648:8680:16b0:c10c:3358:4516:c03f] (unknown [IPv6:2601:648:8680:16b0:c10c:3358:4516:c03f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Plj8T2mBnzJKf; Mon, 27 Mar 2023 19:11:05 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <0f19b708-c167-b05e-1b0d-e4c1029a50c4@FreeBSD.org> Date: Mon, 27 Mar 2023 12:11:03 -0700 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 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Content-Language: en-US To: Brooks Davis , Justin Hibbits Cc: freebsd-arch@freebsd.org References: <20230316100611.4892008c@gonegalt.net> From: John Baldwin Subject: Re: Blocks runtime in the kernel In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N 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. -- John Baldwin