From nobody Thu Sep 12 00:26:14 2024 X-Original-To: freebsd-net@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 4X3ysn4Gflz5Vym1; Thu, 12 Sep 2024 00:26:21 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3ysm1GqYz4M7X; Thu, 12 Sep 2024 00:26:20 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=jwlbnWxx; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of vadimnuclight@gmail.com designates 2a00:1450:4864:20::233 as permitted sender) smtp.mailfrom=vadimnuclight@gmail.com Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-2f75b13c2a8so5057741fa.3; Wed, 11 Sep 2024 17:26:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726100778; x=1726705578; darn=freebsd.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=cYoWHowlaxUIxtahmcQwJ2VDHGzi1OZKXzI/rYfVDfY=; b=jwlbnWxxnS3GL55mBLX7gZVXBFiLGIH6ljRENO0LaB7+MvHFU6HyLoxk2xjm9r1MVG nzOupoNR1juC06bUH7ztouZ8OmeDJvm3ANvXie/aJT2eAkM4oHbKxa+KA35IStImsB80 VkbAHPu2Z1ac6pcJp0QQcE3oQ8tpKuaJlpg2kYTMn4Nx9Q6sQP2YCidDnKVEFZysF08X cw0sBym2ZtBI3luefdW57cQ+CZBBxzhB787cmzTOR8pOTnoBKh0Dcy6AYgF7QT5G4LaD OBhNy9/nGF0UXanf595IigXVJNpZT9MhASvXk+VqVFJ/AB0YypWP+29jbiSOsvxMVfgl 859g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726100778; x=1726705578; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=cYoWHowlaxUIxtahmcQwJ2VDHGzi1OZKXzI/rYfVDfY=; b=QHuYbXeqzgI6Usji1e+EsSYrqy/hSedlFg8knMbInCtcLzYGAtkGWkKZQubNHHgUpd KdI25OwI+gIlDsxlwm/nqpGxGu6prGxEmJ6Q4fCU11HawmiDJzm7SkW9Rx2xFQwoQwZu d0dXCfD1tAaY9lfMJKSSIT0MJzR7OJRdBX7UUuAHDuC1eFBXslqJG9aQDSY0aTj6m+D7 kfAa1P28kD3Q0e6wJ10/iBh6kL71AMXl3z625mUFmsqTQ2g5VtIAe1/oAEnaibFQhElE 2fr/mhd/p1FPEDS1DW46WS0RYdOay8ViQSnjC6RqSsVz2jmYlMgg8TJrZuO8Rac7gQJJ mt5w== X-Forwarded-Encrypted: i=1; AJvYcCXA9etlJIVR002cenHH3bT6WDke6MlfLSnoxs9gerNtSntBDhCXik4xncyF7FaU/vd4pS4NnyALtnZ81LhS/fQ=@freebsd.org, AJvYcCXLT6KCfkdn3b141C114OgYlBzyBQda5gqEGQJUDpAtQdKGm/du4106tMPPzp31W6EpPHBtYIn2G5lQHwU=@freebsd.org X-Gm-Message-State: AOJu0YykR4+1ZRuVWKuiyv71VpVMllbdl9PvhLUu0F5MV+DyVLQfHYmH AHkR7HYAdTzpsuYC6FMdLqaO+xsnv6efYvqhKRlbmB/swlz7JdIU X-Google-Smtp-Source: AGHT+IFG03hcxcakfjwOaJGlKdhk0XrccinW5TqrwyPuUhlOiQiPNISLM95vPsD6s52zTxb4QtHeBw== X-Received: by 2002:a2e:a553:0:b0:2f7:631a:6e21 with SMTP id 38308e7fff4ca-2f787ed5c6amr4932251fa.24.1726100777473; Wed, 11 Sep 2024 17:26:17 -0700 (PDT) Received: from nuclight.lan ([37.204.254.214]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-2f75c008f6csm17091391fa.59.2024.09.11.17.26.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Sep 2024 17:26:17 -0700 (PDT) Date: Thu, 12 Sep 2024 03:26:14 +0300 From: Vadim Goncharov To: Rob Wing Cc: "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , "freebsd-net@freebsd.org" , "tech-net@netbsd.org" Subject: Re: That's how (why) BSD is dying (Was: BPF64) Message-ID: <20240912032614.36796b03@nuclight.lan> In-Reply-To: References: <20240910040544.125245ad@nuclight.lan> <202409100638.48A6cor2090591@critter.freebsd.dk> <20240910144557.4d95052a@nuclight.lan> <4D84AF55-51C7-4C2B-94F7-D486A29E8821@FreeBSD.org> <20240910164447.30039291@nuclight.lan> <3F3533E4-6059-4B4F-825F-6995745FDE35@FreeBSD.org> <20240911011228.161f94db@nuclight.lan> <20240911024735.37522532@nuclight.lan> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; amd64-portbld-freebsd12.4) List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_TO(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::233:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-hackers@freebsd.org,freebsd-net@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4X3ysm1GqYz4M7X On Tue, 10 Sep 2024 16:55:15 -0800 Rob Wing wrote: > On Tuesday, September 10, 2024, Vadim Goncharov > wrote: > > > > > > What's the point to waste resources on writing thing that is known > > to be not accepted to base system from the very beginning? > > > what's the point of talking about thing you're never going to > write/finish even if it was accepted? Because - and I've written that from the beginning - wrong architecture will cost too much if your code already exists, than if fixed before that. So I've received worthy feedback describing problems; not that were good solutions yet, though... > Or even bikesheds are in short supply now? > > have you considered calling it eBPF++ or BPF128? Well, first it was called fBPF as next letter from eBPF, and for 128 it lacks 128 bit arithmetics. Then I realized that for some things there will be different implementations in different kernels, e.g. for atomic(9) operations, so better to call generic common thing neutral BPF64 and e.g. fBPF be FreeBSD dialect, nBPF for NetBSD dialect... > at any rate, don't claim the sky is falling on the grounds that I > think your proposal is far fetched Not you. FreeBSD already had precedent when already written and committed code framework for device sensors was removed: https://lists.freebsd.org/pipermail/cvs-src/2007-October/082398.html and that happened by exactly the same person with similar tone (not you). ...well, ok, there were some really technical arguments in that case e.g. about sysctl_add_oid() but that was the most technical of them, all other being same arrogant rant. Anyway, such cases are very demotivating from contributing. > if you think you've got a great idea and have a need for it, then > write it and use it - if other people adopt it, even better > > all the best to your endeavors and don't let the naysayers hold you > back Well, what I really need is a technical help for areas I don't know, as obviously I won't be able to write entire ecosystem alone. For example, I don't know how many registers are available to a function in a kernel on an ARM, MIPS and RISC-V. If I allocate too much, then somebody will have trouble implementing JIT on such machine, as I don't have such hardware. And e.g. https://en.wikipedia.org/wiki/MIPS_architecture says 2 registers are for kernel - OK, and what if we are kernel itself? :-) Do we need Thread Pointer of Global Pointer, or we can stash them to stack? Etc. -- WBR, @nuclight