liblinux

y first project planned: a custom Rust network stack for my QEMU virtual machines so I can firewall them off in userspace without root access. > the Linux platform The linux platform is these system calls. Everything else is userspace. This is exactly what makes it special. https://www.matheusmoreira.com/articles/linux-system-calls

ke number/string conversion. I simply wrote my own. https://github.com/matheusmoreira/liblinux/tree/master/examp... Linux is the only operating system that lets us do this. In other systems, the C library is part of the kernel interface. Bypassing it like this can and does break things. Go developers once discovered this the hard way. https://www.matheusmoreira.com/articles/linux-system-calls The kernel has their own nolibc infrastructure now, no doubt much better than my project. https://github.com/torvalds/linux/tree/master/tools/include/... I encourage everyone to use it. Note also that _start is an arbitrary symbol. The name is not special at all. It's just some linker default. The ELF header contains a pointer to the entry point, not a symbol. Feel free to choose a nice name!

ub.com/matheusmoreira/liblinux/issues/16 I think it's better to just be sincere and provide the necessary context.

hen they are being non-helpful That made a lot of sense to me. I took that concept and kind of ran with it. Started a liblinux project, essentially a libc with nothing in it but the thinnest possible system call wrappers. Researched quite a bit about glibc's attitude towards Linux to justify it: https://github.com/matheusmoreira/liblinux#why The more I used this stuff, the more I enjoyed it. I was writing freestanding C and interfacing directly with the kernel. The code was so clean. No libc baggage anywhere, not even errno. And I knew this could do literally anything when I wrote a little freestanding program to print my terminal window dimensions. When I did that I knew I could write code to mount disks too if I really wanted to. I was talking to the kernel. Eventually I discovered Linux was already doing the same thing with their own nolibc.h file which they were already using in their own tools. It was a single file back then, by now it's become a sprawling directory full of code: https://github.com/torvalds/linux/tree/master/tools/include/... Even asked Greg Kroah-Hartman on reddit about it once: https://old.reddit.com/r/linux/comments/fx5e4v/im_greg_kroah... Since the kernel was already developing their own awesome headers, I decided to drop liblinux and start lone instead. :)

calling convention and the system call instruction. The right place for system call support is the compiler. We should have a system_call keyword that makes it emit code in the aforementioned calling convention. With this single keyword, it's possible to do literally anything on Linux. Wrappers for every specific system call should be part of every language's standard library with language-specific types and semantics. An example of one such language is Virgil by HN used titzer: https://news.ycombinator.com/item?id=28283632

fficial kernel library at some point. I asked Greg Kroah-Hartman about this and he mentioned there was once a klibc: https://old.reddit.com/r/linux/comments/fx5e4v/im_greg_kroah...

the file system while filtering out all items not matching the given predicate function. It was my intention to provide predicates like c_file? and header_file? but I stopped developing that project before that happened. Users can easily write their own predicates too. I think rwildcard is probably simpler and more efficient! If my code helps in any way though, feel free to use it.

environment vector. No count is provided for that, so code must loop through the environment looking for the sentinel in order to find it. The auxiliary vector is really interesting. I don't usually see software making direct use of it. It contains interesting information such as CPU identifier and capabilities, page size, the location of the Linux vDSO, some random bytes, program file name, user and group IDs, among other things. https://github.com/torvalds/linux/blob/master/include/uapi/l... https://github.com/torvalds/linux/blob/master/arch/x86/inclu... https://github.com/torvalds/linux/blob/master/Documentation/... This is the data the Linux kernel passes to programs. After organizing these parameters, the program is free to do whatever it wants. The libc entry point will naturally start setting up libc. In particular, it seems to spend a lot of time setting up the init and fini insanity that's probably better off forgotten. https://blogs.oracle.com/solaris/post/init-and-fini-processi... It's not necessary. After this, you can just run your program directly. I used to develop a liblinux that illustrates all this with much simpler code: https://github.com/matheusmoreira/liblinux/blob/master/start... https://github.com/matheusmoreira/liblinux/blob/master/start... The entry point code passes the stack pointer to a C function which gathers all kernel parameters and starts the program with no further setup. I made several example programs, including one which outputs all these variables. https://github.com/matheusmoreira/liblinux/blob/master/examp... I stopped developing this because I discovered the Linux itself has a better solution that they use for their own tools: https://github.com/torvalds/linux/blob/master/tools/include/... The entry point code for all supported architectures is present as inline assembly code!

es in order to have a normal main function. The only missing feature is the auxiliary vector. You can just include it and start using Linux immediately. You can absolutely do this with Rust as well. Rust supports programming with no standard library. If I remember correctly, the inline assembly macros are still an unstable feature. It's likely to change in the future though.