From nobody Tue Mar 28 19:43:56 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 4PmKqy4Qhpz42LNy for ; Tue, 28 Mar 2023 19:43:58 +0000 (UTC) (envelope-from jhibbits@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 4PmKqy3fM8z48ld; Tue, 28 Mar 2023 19:43:58 +0000 (UTC) (envelope-from jhibbits@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1680032638; 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=AWFuku7kdBglXCSGateTCXNZvFtqz0005yLDXyvW74M=; b=yFMhhDEhx6GQV5hro8j5tk2/BHOHWCrdFIMNX3EkV6d02z/II97Kbo/5JKmSxeSfbFsJWv w2RQACaMImNUnFfBuYulBvoVt5moWpWGf/uDf2saib1Lu9vuHe9GBDY3PYtjGYw1hM6bfP 9ZaBotwQ5nCv6ErUf/0H9170NEqs4JUZgtka+8JV4aOFgfvZyQODSPRzU+b8peTgVvYA9P HDFT+aBFeP9MOxbqBTUQKFDUchw+Au3hFZ4QMQm0282LF+c9zRvnvOaFpMAeOnYF9SnB0w KziRx/e0W7hp/mRAlPivt33MaoF/dkvxMb4jF8DoCeywpAhOY4yzlHCiIYeQdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1680032638; 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=AWFuku7kdBglXCSGateTCXNZvFtqz0005yLDXyvW74M=; b=UeaCXuEMjLK3hGxyy06whwLKrCnkFKoGGiYkp3rZdCQq6AwbF5SvpEhmOdWKnKTHFvZdQC SRVYiFYRKSRKETLMnfnw4kVP60mKsXpdvQpDuOQowOHX21NJqumPLHMZnLxlDrNdTNQrCo DVXZppaMlOoX2Dh0SYXOKvwR9/0eqxzX38O3awXhfUm6GbNObjMIxHCVDFNX++oQLHsxP9 4uGw5RW13ccVXtq+Hz3I/ss3oGUwjCRzrqemF4CvjlfkBww7PlYe3qtUHzw2qIFKwLvLa2 RawIuFC+CKvfn9SFCDjYc9kp+4ebPg7Er2PR/mI8AxrAiLBJ0RutCDwvp48UQg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1680032638; a=rsa-sha256; cv=none; b=VilH9GESbblKL64ftDrZpLmCD2UaC9l7M79UBt4s7RHDRukCr2SH3Hy8jjJ0IQ6EzndLrD Dr62cx8EAFQPbDyEyVt0dRPQVv5583Tgr3dtdBXETAEs/BPU4eTUbWEc+FOebZgHkZak3y pvewO4qHl4sX81tC5PdBw04CHajo96o9CF9rY/MOjLZRBXNj8w0xWLIWBfaC4227TsAeOZ A0OCLHpMjIxTIfdCmZUkbrnmMECs1e1C2a1XRPXh71SUm7As66LrA9ItwRPXF3zdA2J1Uv 1R27Tg5jHbuPFyJn9JNCqQ9I5lCIqpqHmgXyrv6JXyigbxKBnWNNxogljq6w8A== 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 4PmKqy1FXTzkn6; Tue, 28 Mar 2023 19:43:58 +0000 (UTC) (envelope-from jhibbits@FreeBSD.org) Date: Tue, 28 Mar 2023 15:43:56 -0400 From: Justin Hibbits To: Konstantin Belousov Cc: John Baldwin , Brooks Davis , freebsd-arch@freebsd.org Subject: Re: Blocks runtime in the kernel Message-ID: <20230328154356.7130e4e0@gonegalt.net> In-Reply-To: References: <20230316100611.4892008c@gonegalt.net> <0f19b708-c167-b05e-1b0d-e4c1029a50c4@FreeBSD.org> 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 Tue, 28 Mar 2023 01:14:42 +0300 Konstantin Belousov 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