Re: deconflicting new syscall numbers for 6.11

["Jason A. Donenfeld" <Jason@zx2c4.com>]

Hi Linus,

On Fri, Jul 05, 2024 at 12:46:37PM -0700, Linus Torvalds wrote:
> If saying "the state size is fixed at 256 bytes" means that ten years
> from now, we won't be updating to some super-duper fancy new algorithm
> that wants to keep a huge state size - then that's a GOOD thing.

I'm all for avoiding fanciness. I can imagine three plausible scenarios
where we benefit from the kernel doing the allocation, rather than mmap,
or where it's nice to have the kernel decide on the size:

- On some platform, it's actually more efficient to generate N blocks,
  such that the state there needs to be larger.

- The amount of state that we buffer increases according to some speed
  vs practicality trade off that changes. (Right now we buffer 1.5
  blocks; maybe 3.5 would be better eventually.)

- We find out that there's a better way of doing all this with a special
  mapping instead, or some other means.

What I have in mind, IOW, isn't fanciness. But alright, let me run with
where you're urging me and see where that takes things. 

> Side note: you could just stick the size as a constant in the vdso too.

Yea, this sounds more like solution (4) from my last email. I'll give
that a shot and see what it's like nuking the syscall. I'll ping here
when v21 of the series is ready, and hopefully you like it more.

Thanks for brainstorming this all with me.

Jason