Re: That's how (why) BSD is dying (Was: BPF64)

On Tue, 10 Sep 2024 16:55:15 -0800
Rob Wing <rob.fx907@gmail.com> wrote:

> On Tuesday, September 10, 2024, Vadim Goncharov
> <vadimnuclight@gmail.com> 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