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
>>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 :^)
>>107814852>streams need a buffer on libc (and duplicated on the kernel for some reason.)How tf are you even going to handle streams without a buffer in the kernel? imagine pipes, those are a kernel level abstraction, you need to have buffers in kernel to make them work at all, let alone performantly, and obviously libc needs to store it in a more easily accessible place.
>>107817097Oh wow, that's cool. I've had a couple projects where I had to interface with some other program that only accepted files as inputs, and I've had to create temporary files in /tmp or the pwd to get around that. This could be useful.
>>107821288shared circbuff mmaps as ipc. other anon also listed syscalls that facilitate shared maps for zero kernel copy.
>>107814794And a numpad. Larping programmer detected.
>>107813965Look at clone and futex syscalls once you're done with the elementary stuff. Parallelism in low-level code is ten times easier on Linux. libc is holding you back
>>107817097>>107821309>Check out O_TMPFILEwhy do lintards basedface themselves over basic bitch options that every win32 developer knows about?
>>107813965>_NR_fstat is the Austrian empire (A.E.I.O.U.)>_NR_lstat is the Man (...)musl libc is complicit
>>107813965We're not even ten syscalls in and we're already brushing up against a historical wart of UNIX: lstat(2). Symbolic links complicate everything and lstat(2) is one of the gnarly escape hatches that actually let you interact with them. Similarly, stat is gnarly because it's almost always a ToCToU issue unless you're implementing ls.
>>107817097>>107821360The wild thing is that for once NT got it wrong. The point of O_TMPFILE is to create an anonymous file that you cannot interact with externally. That said, it's a gnarly hack that probably shouldn't exist to begin with. Files for IPC are just fundamentally fucked up. Temporary files are nothing but fancy IPC. A program that needs to keep more state than available RAM allows needs a proper, non-temporary file to resume from anyway.
>>107821317That is still an option between two programs you want to work together. You could probably make a shell that does that for pipes. But I understand, my question was out of place, I thought you were saying that the implementation of the file based abstraction was the problem, not the abstraction itself..>>107821317It's not all linux developers, it's about one specific retard(me) who didn't know this. Let me have my knowledge growth faggit.
>>107814852Everything is a file is a result of a PDP-11 having no memory. The correct abstraction would be message-passing IPC. The microkernel people had the right idea, just not computers fast enough to use it. GNU/Hurd went down that path off an evolutionary dead-end. seL4 is doing fine. Nintendo consoles since 2011 proved microkernels in production.
>>107821652the easiest way to make pipes fast is to use splice on both sides, yeah. not sure how a shell can handle that since all it does is match pipe to pipe, no data is marshaled in the shell itself.
>>107821574>The point of O_TMPFILE is to create an anonymous file that you cannot interact with externallyThat's stupid because everyone assumes that a file has a name. If you suddenly create files that don't have names, then code that makes the (very reasonable) assumption that a file handle can be queried for a path and a name will break.Moreover, if you want to block other people from interfering with the file, just omit FILE_SHARE_WRITE.I believe the real reason Win32 has this option in the first place is because in the underlying NT API, there is no syscall to "delete" a file. You just open it with DELETE access, and specify OBJ_DELETE_ON_CLOSE in the OBJECT_ATTRIBUTES structure, and then just close the handle. Then the file disappears.
>>107817765you could think about it the other way. Are there jobs where I get top play around with syscalls while making a 6-figure salary? Yeah, there's plenty of those.
>>107821899>I believe the real reason Win32 has this option in the first place is because in the underlying NT API, there is no syscall to "delete" a file. You just open it with DELETE access, and specify OBJ_DELETE_ON_CLOSE in the OBJECT_ATTRIBUTES structure, and then just close the handle. Then the file disappears.Nevermind, I just hallucinated all that. Turns out I'm no better than a LLM. There is NtDeleteFile, I just didn't know about its existence until just now.
>>107817765if it's not your hobby, why do you still come here? I'm serious, I see people make similar posts on this board all the time about how they only do programming for work etcwhy waste your time on a hobby board?
>>107821899it is nice that you don't have to worry about finding a valid new filename with this flag.also it sucks in general that processes assume that files always have to be linked. I frequently delete the folder I have a shell opened in as cwd and a program I run fails in a perplexing way. for files it's less of a problem because I guess most programs get and keep the file path in a variable very early on.>>107821309only if it needs to be seekable. most unix programs seem to work with streams well, the bigger problem is the retarded ones where they parse the filename extension for its processing logic, which this wouldn't fix
>>107821574filepaths are useful because they let you define a variable length number of them as args whereas 6<file is limited by fd count. it's maybe less work done too if the files are lazily opened by the callee.
>>107821360What happens after a system crash? An O_TMPFILE would get cleaned up by fsck as an orphaned inode, but it seems like these files might stick around if only the handle knew that it was supposed to get deleted?>>107821899>That's stupid because everyone assumes that a file has a name. If you suddenly create files that don't have names, then code that makes the (very reasonable) assumption that a file handle can be queried for a path and a name will break.There are many crazier kinds of file descriptors already and AFAICT there's no portable interface for getting a filename from a descriptor. I don't think this is a big deal.Doesn't NT put an even greater variety of resources behind HANDLE pointers than Unix does behind file descriptors?
>>107823362>Doesn't NT put an even greater variety of resources behind HANDLE pointersI specifically said file handle. NT uses handles for lots of things but the "everything is a file" abstraction isn't really a thing on Windows, no one considers e.g. events or mutexes files.>What happens after a system crash?Probably nothing. If you put your file in one of the standard temp folders, it'll get removed by disk cleanup.
>>107821941I missed the bit where this was a programming board. Then again you only need to read tech workers general to realize that all anyone thinks "tech" is, is programming.
>>107821340we are going in order (https://boards.4chan.org/g/thread/107824139)we'll get there eventually! clone isn't too crazy far off, i guess
>>107824182it is a bit annoying that the url didn't get parsed>>107824139
>>107813965Is there a standard built-in in C for making system calls or do you have to resort to implementation-specific inline assembly or separately assembled files?
>>107824582You could use https://linux.die.net/man/2/syscall
>>107824669Forgot to add that I don't want to link against libc
>>107824694In that case I don't think there's anything built into the language no
>>107824582because syscalls are, by definition, implementation-specific, you have to use implementation-specific assembly at their core, they're just magic numbered transaction IDs
>>107824847I thought you could work around it by providing a cross-platform built-in equivalent of x86's syscall instruction and then just use it inside of a function but now that I'm reading about it, it seems like Linux doesn't even use the same calling convention for 64-bit user space programs and system calls. I guess the compiler would have to detect the usage of said built-in in function bodies and then change the way arguments are passed to them once they're compiled. It would (probably) also have to be the first and only statement because any code executed between parameter setup and the actual syscall could influence the contents of registers.
>>107813965>file iook I have something tangentially relatedis there a way to differentiate between "special" files like /proc entries or character devices and those that actually support random access and other common operations?
