i noticed, today, that there are currently 363 x86 syscalls listed in musl libc: https://git.musl-libc.org/cgit/musl/tree/arch/x86_64/bits/syscall.h.ini thought that this would make for a really good "syscall of the day" discussion (nevermind the fact that it's already the 9th)for today, in order to catch us up, as well as maybe foster a bit more discussion and interest, we'll actually start with 7 syscalls. these are: #define __NR_read 0#define __NR_write 1#define __NR_open 2#define __NR_close 3#define __NR_stat 4#define __NR_fstat 5#define __NR_lstat 6luckily for us, these are all pretty similar, so it really works out quite nicely. these are your classic, day one syscalls that pretty much every programmer ought to know about, even if they don't care to delve too deeply into the internals of the system.ITT, feel free to discuss these syscalls, syscalls in general, file io, and other related topicsmy personal suggestion for those who want to get a better understanding of lower level linux but don't know where to start is to just go back to the well, so to speak, and do the classic "Hello, world!" exercise, but compile with -nostdlib (or just -nodefaultlibs if you want to be lazy). once you've managed to get that done, adding on new syscalls becomes much easierrelevant resources: man manman syscallshttps://man7.org/linux/man-pages/https://linux.die.net/man/https://elixir.bootlin.com/linux/https://elixir.bootlin.com/musl/https://elixir.bootlin.com/glibc/
#define __NR_read 0#define __NR_write 1#define __NR_open 2#define __NR_close 3#define __NR_stat 4#define __NR_fstat 5#define __NR_lstat 6
-nostdlib
-nodefaultlibs
man man
man syscalls
sorry, your thread is off topic. /g/ is for posting kids and AI slop
>>107813965I'm trying to dive deeper into my knowledge of Linux and Os's in general. What's a good source to learn about Linux's syscalls? Books preferred
>>107814137i have never read a programming book (in my experience, printed text and code don't mesh super well), but there are a significant number of university (including some of the top in the world) lectures on OSes available for free onlinehttps://www.youtube.com/results?search_query=advanced+operating+systemsi definitely recommend hands-on experimentation over reading or watching things, though. they're honestly not even comparable. you will not learn unless you do. it's really as simple as that
>>107813965I applaud you for making and interesting and useful thread, sadly it will die, wiped out by slop and bot spam.In any case, Advanced Programming in the UNIX Environment and The Linux Programming Interface are fascinating and useful reads.Many times I want to delve deeper into this stuff, but then I remember it has no real use to me and the clock is ticking and I'm running out of time.... But on the other hand, does anything matter? Is one thing more useful than another, to spend time on? None of this nor that is getting me a high paying job or anything anyway.
>>107813965Missing a row
>>107813965the everything is a file abstraction kinda sucks. file reads need a buffer over the block device, streams need a buffer on libc (and duplicated on the kernel for some reason.) block devices exposed as files is even more dumb when it attempts to hack on an abstraction that's just woefully underpowered.the real abstraction is to be found at the common denominator between all of the implementations they hide. everything is a linear slice of memory.
>>107814852>and duplicated on the kernel for some reasoni'm getting ahead of myself here, but i imagine you'll be a fan of the __NR_sendfile, __NR_splice, and __NR_copy_file_range days if you dislike unnecessary duplication of resources
>>107813965cool thread anon
>>107814917read a little on all of them, they're cool. the insight largely seems to be to work on / rewrite metadata instead.
bumping a bit
>muslslop
>>107813965>__NR_openYou could fill a week with this one alone. Check out O_TMPFILE
__NR_open
>>107813965lick lick lick pero pero pero
>>107817361would you really want to lick a programmer girl's toes? do you have any idea where those things have been?
>>107813965synchronous IO syscalls are a mistake
>>107817686Yeah, in my mouth.
I have never needed to use syscalls directly in my life.I'm not proud of it, but I'm not going to need it to keep earning a decent 6-figures salary. Such is life.
>>107817765I've only ever directly made syscalls for pleasure, not for business, but understanding what strace is talking about is very helpful every now and then
>>107817731l-lewd >_<
>>107813965finally i good bread that i can enjoythank 4 bake OP
>>107813965based breadi am yet to write any syscalls outside of schoolwork despite working on linux device drivers for work because i'm only ever in kernel space :^)
