bampu

This is one of the few threads with a single syscall (as opposed to e.g. __NR_io_setup, __NR_io_destroy, __NR_io_...). Haven't seen one like this in a while (but I don't check all of them).

On the first thread, you started this project because there were about 365 syscalls, so one a day would last a whole year. Do threads with several syscalls mean we'll finish before the year is up or did I misunderstand and there are about 365 manpages (which may include multple syscalls)?

Because I already don't know what I'll do in 2027 without this daily autismo, and if I'm blindsided by it ending too fast... I don't even want to think about that, anon!

>>108772834
>what sort of syscall would you want to create, anon?
(You) are literally the most expert in syscalls I know, op. What syscall do (you) feel is missing?

Also, do you know about the process of creating a new syscall? You just make a patch and submit it to kernel dev mailing lists? Or is it an RFC that needs to bureaucratically accepted into POSIX? Or something else entirely? Or even you don't know that (it's okay, it is tangential to the topic at best)?

>>108773705
yes, we're going to finish early. i started out doing only one a day, but it seemed like it was really difficult to keep up attention having back to back days with get/set, create/destroy, etc. pairs of syscalls on the same topic
we are coming up on the end sooner rather than later! :v
once it's done, i'll probably do some architecture specific ones, then we can revisit some people's favorites/ones that they missed, and finally we can talk generally about syscalls. i probably won't continue it forever, though

>>108773738
hmmm, that's a good question. honestly, it's pretty niche, and i doubt it would get used much at all, but a "cleanup/reset" syscall which effectively performed the cleanup that an exec/exit does, but without actually execing anything/dying would be nice. it might just get a little complicated depending on how you wanted to bootstrap the new process. but it could have flags for whether it should close fds, reset X, Y, Z things inherited or not inherited on fork/exec, etc. it could allow for much lazier C programming where you just leak everything and occasionally call that syscall to clean it all up
not sure how you'd go about getting it actually merged in. presumably it would start with a technical document/spec, a proposal, code submission, etc.

>>108773793
lmao, that would be horrible, but probably also nigh unimplementable. if it does a full reset, what's the point, you might as well exec the programme anew.
If it doesn't, it gets incredibly hairy what exactly is kept. Is mapped memory kept? Surely the stack is kept? What about modified memory in bss and data? Is it reset to its initial state?

>>108774043
honestly, i don't think it would be that bad at all. it would basically perform all the steps that an exec would, except it would dump you at the linker with all the library handles you had open marked as DT_NEEDED
desu, rather than a new syscall, it would be nice to implement this as a flag to clone. that way you can more efficiently fork (sort of like a vfork), except you dump all the startup cost onto the child. so like a fork+re-exec to clean up your process, without actually having to exec

>>108774065
Not to be that guy, ebussi, but what is the actual use case? You mentioned leaks earlier. Would you program in C with leaks and then do a clenaup syscall to "GC"? Your program would have to be completely stateless that it would stay usable after that. I think. It would bring it back to the same state as if you killed and started a new instance? Like some "exec $0 $@" on itself? Or maybe I'm misunderstanding the whole thing, but state after calling it = cleanest state when the program just starts?

>>108775174
there isn't really one. it's a bit contrived, since i was trying to come up with a new syscall on the spot

>>108772834
This maid is very cute. Good thread.

>>108775194
well! do better next time!°^°