OSDev.org

Regarding loadable modules, dynamic linking is implemented in userspace in many systems. Surely, a program requiring loadable modules could have its own dynamic linker. I'm sorry if the point has been made already; I didn't understand some of the terms.


The Plan 9 linker is very good at eliminating unreachable code. This means memory is used with per-function granularity, while dynamic linking can't manage better than per-page granularity. However, this got me thinking about the complexity of the linker -- it's known to be slow. This is one area where static linking wants more complexity than dynamic.


Flatpacks etc. are what Windows and commercial Linux programs were doing all along: just bundle the libraries. It's always been inefficient and technically pointless, but it's always been necessary where static linking is, for whatever reason, unavailable. (The LGPL would be one reason.)

AndrewAPrice wrote:Sorry, I mean to say there is no "file open" system call.

Well, what's the point of that? You end up with a bunch of "dynamic" system calls you need in almost every application anyway. I suspect that all I/O system calls are dynamic in this way. Thus all of your applications end up doing a theoretically dynamic initialization that is going to turn out the same for all of them. Basically what a dynamic linker does.

See, OS-9 pushes all I/O system calls to the IOMAN program. The kernel itself contains only a stub for doing exactly that. This does however mean that there is a stable "open" system call with the same ABI as the memory and process system calls, and the fact that they're RPCs under the hood doesn't have to concern the program running the call. (If you're wondering why I keep bringing up OS-9, it's basically the only microkernel OS I know in any depth).

AndrewAPrice wrote:However a simple GUI calculator program is 9MB in my OS.

[...]I'd appreciate it if anyone has any advice on how I can shrink my binaries.

I suspect it's because my UI library uses skia for drawing, and by touching it for a few things (e.g. drawing some text and buttons) I end up touching a lot of unused but plausibly reachable code paths and all of skias dependencies get linked in.

I know entire operating systems that aren't this large. My advice is to use "nm" to analyze the symbols linked into the binary. Check if you can reduce the dependency chains.

nullplan wrote:

AndrewAPrice wrote:Sorry, I mean to say there is no "file open" system call.

Well, what's the point of that?

I don't believe most microkernels provide a "file open" system call? They usually concern themselves with IPCs and sometimes scheduling. For example:

https://wiki.minix3.org/doku.php?id=dev ... :kernelapi
https://os.inf.tu-dresden.de/L4/l4man.html
https://www.gnu.org/software/hurd/gnumach-doc/mach.pdf

Microkernels exaggerate how an operating system is not just the kernel, but the entire ecosystem. (The extreme opposite of this, where kernel = OS, would be a monolithic kernel contains the window manager, file manager, and everything other than user applications.)

AndrewAPrice wrote:https://wiki.minix3.org/doku.php?id=dev ... :kernelapi

Minix has an open() syscall. It works like I outlined for OS-9 above: The arguments are sent to a server (in this case the VFS server) immediately, and the call blocks waiting for a response. Yes, the kernel doesn't do much, but it does provide a first-level syscall handler to handle the open() call. In particular, it can never happen that the open() call is not available.

nullplan wrote:

AndrewAPrice wrote:https://wiki.minix3.org/doku.php?id=dev ... :kernelapi

Minix has an open() syscall. It works like I outlined for OS-9 above: The arguments are sent to a server (in this case the VFS server) immediately, and the call blocks waiting for a response. Yes, the kernel doesn't do much, but it does provide a first-level syscall handler to handle the open() call. In particular, it can never happen that the open() call is not available.

That's basically how my new VFS works. There is a kernel side syscall interface the application use which will send a message to the VFS and block until the answer is ready. However, unlike the typical Posix compatible OS, I do not use this method for read and write. Instead, I have a piece of code in userspace that handles memory mapping the file and requesting new portions to be mapped when necessary. This eliminates most syscalls, particularly if the application reads small chunks of a file at a time.

My Comments:

About 1st: Dynamic linking in Plan9 is solved somewhat different. Everyone knows that in Plan9 everything is statically linked (as same as in golang) but there is more to it.

Services such as network, authentication and other are not libraries but servers with mounted filesystems. Everything goes through files as text. So there update to, for example, TLS encrypted connections would only be performed once - you need to update the network server.

About 5th: the ddl hell comes from overlooked idea that programs expect certain behavior from certain version of a dynamic library. If that behavior changes then system has to maintain multiple version of that function. We, programmers, just like to overcomplicate things.

My main idea (as a Plan9 fan) is that many, many things should not be libraries but programs, servers etc.

Post Scriptum. I know. Don't mention GNU Hurd.

arseniuss wrote:My main idea (as a Plan9 fan) is that many, many things should not be libraries but programs, servers etc.

Post Scriptum. I know. Don't mention GNU Hurd.

Can I mention QNX instead? I mention it because of a claim that it's easy to write services for QNX. (See the famous QNX demo floppy.) Anything you can do with fileservers in Plan 9, you can do with services in a microkernel, but it's not easy to write fileservers for Plan 9.

Oh! Oh oh oh! I just realised how relevant the old QNX demo is to the topic. They got a full GUI, 90s web browser, and other things onto a single 1.44MB floppy. The window system itself is described as a microkernel with optional cooperating processes -- see screenshot.