Well, it was not hard for me to add batching for every syscall. The whole module is under 200 lines of C. Granted, I only did x86_64.
I think it has some bearing to those using eBPF to just batch calls, too. Unless I am missing something, I do not think there needs to be any super-user/root/capability restriction on syscall batching since all the syscalls check permission "on the inside". That gives it maybe more scope for applications.
That sys_batch is kind of a tiny "jump-forward-only" assembly language where you can use the output of prior calls in later ones. The jump forward only (no loops) I do should also guarantee termination { at least conditioned upon all syscalls terminating...but that's a whole other domain ;-) }. (EDIT: IIRC, the article that this conversation is about was excited about this aspect. In my examples/ I have an "mmap a whole file in one syscall" example.)
I don't personally find such naive syscall batching flexible enough to be all that useful.
No ability to do such common things as concatenate strings from syscall results, or branch according to stat() output for example, makes for a severely limited interface.
io_uring is already in mainline, and it delivers syscall batching as a side-effect while bringing async to the table. I just don't see the point in adding another, severely limited syscall batching thingy, certainly not now, even moreso with talk about ebpf logic joining the party.
BTW as mentioned in a sibling comment, you might want to check out mingo's syslets proposition, which has similar naive batching, but was also async.
It can branch based on the syscall return and the ability to copy word-values like file descriptors from open to an fstat and so on. That copying could perhaps be extended to strings in some limited way, but I agree it is generally much more limited.
Not needing superuser/any special capability is also nice, though. Not sure of the current status/plans, but I am pretty sure eBPF needed root that for a very long time.
Anyway, I was not trying to "compete" with you or try to "get into mainline". A module works fine for me. Was just exhibiting an easy possibility about some points discussed.
EDIT: and thanks for the pointer. I will check it out.
EDIT2: and much like the word copy is a fake syscall, other fake syscalls like a "value test" could be added to forge a sort of if condition jump forward thing. My little repo there is more a proof of concept than anything else.
It's not like I have a dog in this race, I'm just another consumer of these kernel interfaces...
But I am happy something finally has landed upstream we can start writing generic userspace programs targeting and actually expect them to work on distro kernels in the future. But we probably still need a compatibility layer for emulating it in userspace, looks feasible.
Ah. "Contributions are welcome" made me think of you as one of the welcomers.
Compatibility-layer-wise, I did actually do that for my batch system. In the tiny user-space entry point I check if sys_batch is working and if not I fall back to just a loop of userspace making syscalls. That also checks a BATCH_EMUL environment variable to force that emulation mode for benchmarking purposes { so I don't have to unload/reload the module. :-) }
So, user code would always just work, but work faster on kernels with the module loaded.
I've just been following the io_uring mailing list as of late. It appears to be a welcoming environment to outside contribution, assuming quality and relevance of course.
I think it has some bearing to those using eBPF to just batch calls, too. Unless I am missing something, I do not think there needs to be any super-user/root/capability restriction on syscall batching since all the syscalls check permission "on the inside". That gives it maybe more scope for applications.
That sys_batch is kind of a tiny "jump-forward-only" assembly language where you can use the output of prior calls in later ones. The jump forward only (no loops) I do should also guarantee termination { at least conditioned upon all syscalls terminating...but that's a whole other domain ;-) }. (EDIT: IIRC, the article that this conversation is about was excited about this aspect. In my examples/ I have an "mmap a whole file in one syscall" example.)