previous: >>107824139#define __NR_lseek 8now this is an interesting one. it feels a bit strange to have a separate file offset whose information is stored in a totally opaque container, where you can only query information about it via some API. not to mention the following:>If the O_APPEND file status flag is set on the open file description, then a write(2) always moves the file offset to the end of the file, regardless of the use of lseek().>Some devices are incapable of seeking and POSIX does not specify which devices must support lseek().relevant 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_lseek 8
man man
man syscalls
it would appear that L'Seek is not very popular
why even use a syscall can't just do the hardware yourself would be faster instead of waiting for the kernal what if its busy doing other things like internet
You'll get bored of this after a week
>>107834380potentially, but i'm hoping to keep it up for as long as possible
sój thread
>>107833909nice fat anime breasts
>>107834589thanks i have been told she's just like me fr
>>107833909name of anime?
>>107833909anybody here use or know about eBPF? Sounds really cool, sending instructions to a virtual machine inside the kernel. Of course, I can barely program in userspace, I have no idea what I would do in the kernel space, but one day I'll get there. I have to learn syscalls and C, then I can start.
>>107835319Bubblegum Crysis
>>107835319Bubblecoom Crisis
>>107834373in linux, everything is a file. you can't just use hardware apis but have to go through an abstraction (which will just tell you that the operation isn't supported for non-files)
>>107833909i nominate mmap as tomorrow's syscall, as it is the best syscall of all time. the design of bsd's virtual memory system is brilliant
>>107834373everything would have to be done in kernel mode if you were to do things this way and a big benefit of kernel mediating all requests for device ops is it handles the scheduling. stuff like networking doesn't freeze the kernel either, the operation is performed by a device separate from your cpu and will just r/w data to some kernel-reserved portion of ram while your cpu executes other things. disk ops also take a lot of time but since they happen asynchronously the kernel can block your process and pass cpu time off to another process while waitingbasically without syscalls you wouldn't have any protections or abstractions or much of an os at all, it wouldn't be faster, programming would be hell and performance would be abysmalthere's definitely more nuance to everything but that's the best general answer i can bother to write
Another really good resource for syscall programming is the nolibc library in the linux kernel source code.https://github.com/torvalds/linux/tree/master/tools/include/nolibcEach arch_***.h file shows how to make a syscall on different architectures, and sometimes there's interesting comments or interesting examples that show how a minimal libc implementation could be written on-top of syscalls.I wrote a bunch of syscall-only programs because you can copy the executable into a virtual filesystem as "/bin/init" and it will run by itself with nothing else on-top of a linux kernel. A tar file with just that one executable can be imported into Windows WSL as it's own standalone linux distro and then you can brag and say "yeah I wrote my own linux distro from scratch. It calls you a random slur and then crashes".programming with syscalls kind of blows because it's hyped as "stable" so you would think the man pages have like 20+ years of polish but they still suck.> lseek man page doesn't say if off_t is 32-bits or 64-bits, or if it's signed or unsigned > man page for off_t only says it's a "signed integer (as specified under POSIX 2001)"> find POSIX 2001 docs, search for a while, find the specification of off_t> "off_t is a signed integer"
>>107837104i agree that it is indeed the best syscall of all time. luckily for us, it also is the next one in line
