From nobody Thu Mar 16 15:22:22 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 4Pcrbh0mM2z3yFH3 for ; Thu, 16 Mar 2023 15:22:24 +0000 (UTC) (envelope-from jhibbits@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4Pcrbh0KSDz3Q7Y; Thu, 16 Mar 2023 15:22:24 +0000 (UTC) (envelope-from jhibbits@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1678980144; 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=PjrJ+vfw1I6+FlqrVqleqRrh/kum8zo09HBZyUdTPSY=; b=Np5Q1t5mErIHAIvy3U/XXjktxG0CzY4akcCawu5XHvdBTxVjvH3Xpic86HdK657+cYI8ul 9MriLBpmaqVi6xBbG0HZz7u7irnriuBd8vx9rgLcNCE0mxSQd76u2NUtGns1gWUKa6BA8p mPApecssgx/ekbwEJe2MLsei44ZERn8qXK3/ObHlfOQ3ZxuXrDoKvJktc/TZv6ExVZlbi3 surQhbvdjiGAFWMsbQsGEZllp9PAGY4t6TVc3qs1FCLHXI9OXZCXbHAiYRV/aFyNfyuAxR bPUqvHFin3Sj+qSQ8lTDUDmBUbkUB1SYxsZVOIulm5y9MDTrdWDGDG3AXGKjuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1678980144; 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=PjrJ+vfw1I6+FlqrVqleqRrh/kum8zo09HBZyUdTPSY=; b=Ek0SloHGUOhev0ANXmVv0nTUlxuG9PIeQK1tMSRZNMQgiNARgvkSqrHkfwP1yQ1UMP+Yke c6gAgqGMQTzAC87Qt9fNGS9oFkudWaKFlOocZumvy2WitSt3mHnlJ/kpazb94aKwPYrrIQ 2nUg/mG2JBb4gyVsDjjNUwBiZnuRjp8UT2v/Ui/UIX4uZVd4guSaV0Nd5+d91ZLC5QMQao swk3f6K2sW33bB+F0Y2qojQrXvonLyNeZYCawxEc6DbRH7FT0my9vwx26pngqjMKiC8OuM GEIl80sm9zf2AWFDksXBz88OBzy0Yhq0ztUcQ++3jhsOfkdPMNsQiXsWPuUH5g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1678980144; a=rsa-sha256; cv=none; b=jfVjc3ZQ2q0tZBFDVcQ4PrCpcPzGSiMGspxHAu1B2i23dDoJS1iVjGi+1ovI/9u/Uw9fJX uQGGKbx89rSI0DMgxpWuGCSLGCdhlmf8OhnnrI3v9Bbpvzc9DOJhpzRIVKlAut2fxX88Jx OeMlFRZzyVx8FOzvGZFWquvk8pTXIpuftTF/uDIhBJF5TwepcUNDwrefuh4WmqyWZzk7Tb cEp3Dnbfg5FSsyJ+UuRR14oLQ+PsUeIfW7Xzezb2VpYFmInQ/SKKfMRRUQ0D/Pfjq9zV8w T5ogxpApQvUr/Fn5fQLgeiJZkSB9x8PX4AVlxQnHVwGM/8nXv8D0HFyBSug9aA== Received: from gonegalt.net (ip-163-182-7-56.dynamic.fuse.net [163.182.7.56]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhibbits) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Pcrbg5YyyzZVC; Thu, 16 Mar 2023 15:22:23 +0000 (UTC) (envelope-from jhibbits@FreeBSD.org) Date: Thu, 16 Mar 2023 11:22:22 -0400 From: Justin Hibbits To: Warner Losh Cc: "freebsd-arch@freebsd.org" Subject: Re: Blocks runtime in the kernel Message-ID: <20230316112222.31b1620e@gonegalt.net> In-Reply-To: References: <20230316100611.4892008c@gonegalt.net> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.34; powerpc64le-unknown-linux-gnu) 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-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N On Thu, 16 Mar 2023 09:04:29 -0600 Warner Losh wrote: > On Thu, Mar 16, 2023, 8:06 AM 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. > > > > What do you think? > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 > > Suggests that there were issues upstreaming the apple code. So > there's that. The gcc12 port I have can't cope with the sample blocks > code I found on Wikipedia: > /* blocks-test.c */ > #include > #include > /* Type of block taking nothing returning an int */ > typedef int (^IntBlock)(); > > IntBlock MakeCounter(int start, int increment) { > __block int i = start; > > return Block_copy( ^(void) { > int ret = i; > i += increment; > return ret; > }); > > } > > int main(void) { > IntBlock mycounter = MakeCounter(5, 2); > printf("First call: %d\n", mycounter()); > printf("Second call: %d\n", mycounter()); > printf("Third call: %d\n", mycounter()); > > /* because it was copied, it must also be released */ > Block_release(mycounter); > > return 0; > } > > Our current clang is OK: > % clang -fblocks a.c -o a -lBlocksRuntime > % > > But there's no current users of __block in the kernel. There's no > kernel-specific Block.h file, > there's no references to BlockRuntime anywhere in the kernel tree and > the code in > contrib/llvm-project/compiler-rt/lib/BlocksRuntime is completely > userland specific. There > is no kernel support that I could see, since we don't have a > libkern/OSAtomic.h. I'm happy > to be corrected on this though: I've never tried to use blocks in the > kernel and this is grep > level confidence. > > Clang also doesn't enable blocks unless you pass it -fblock, so you'd > need to change a fair > portion of the kernel build system to enable that. > > So I'm thinking regardless of whether or not the project should do > this, you'll have a fair amount > of choppy waves ahead of you before you could get to the point of > starting the ifnet work. > > Warner Hi Warner, I did a very very simple test to see what is required link-wise for blocks in kernel. This was done by changing https://reviews.freebsd.org/D38962 to use a block instead of a callback for the "bootpc_init_count_if_cb". I didn't include Block.h or anything, and simply added "-fblocks" to kern.mk. The result is it compiles fine, then fails to link (expected) with the following missing symbols: _Block_object_dispose _Block_object_assign _NSConcreteStackBlock Reading through contrib/llvm-project/compiler-rt/lib/BlocksRuntime/runtime.c these missing symbols look straightforward to implement for the basic case. I'm not thinking of working within the Clang runtime.c, I'm thinking of reimplementing the needed functions for this constrained use case (no need for GC, etc). This testing was only marginally more than you did, so I'm probably missing some things as well for more complex use cases. I'm guessing from GCC's issues that this is a nonstarter anyway? - Justin