To POSIX or not to POSIX

[Korona]

IMO the really great invention of UNIX is not "everything is accessible via the file system" but rather "everything is a file descriptor". On the other hand, I think that Plan9's "everything is a text stream" is heavily misguided and a very bad idea. It's an oversimplification that prevents many operations from being implemented efficiently. Yes, Linux and BSDs are ugly and they need hacks like ioctl(). But that's just because the real world is ugly and complicated and not ideal and nice .

[eekee]

Apparently, Thompson & Ritchie didn't think too badly of ioctl. I was surprised when I read that.

Plan 9 performance I don't want to argue about, but I won't be really convinced until I make some tests. OTOH I'd rather have proper byte-swapping than text conversion for communication on a heterogenous network. Plan 9 does some things in binary, (bitmaps, audio data, directory data, ...) mandating little-endian. *shrug*

[nyc]

There are also features to consider removing outright, such as fork() as per https://www.microsoft.com/en-us/researc ... otos19.pdf or, perhaps, much of the tty/pty infrastructure in UNIX and POSIX beyond just devising better-working features instead of POSIX threading and asynchronous IO.

I don't find fork() that horrible, but it should be implemented late in the OS and after there is a CreateProcess-like interface. It's a fun challenge to get fork() right, and I don't think every odd feature of it must be supported.

I find the use of file handles for non-file objects a lot more horrible. I think this too go back to horrible UNIX hacks that are 50 years old and that should not be supported in modern OSes. I started out by refusing to support this hack, and instead users had to create a handle for the resource in question, and then need to use the functions defined for that resource-type only. So, when a a socket is created, a socket handle is returned, and it cannot be used it with write() or WriteFile(). I handle the C handle stuff simply by providing read/write (and a few other) methods for the resource-types that could be associated with C handles. This way I keep the object separation intact, but still support these horrible hacks. In fact, I think this way of handling C handles make fork() a lot more simple. Fork just duplicated the C handle translation table for the process which is kept in kernel. Resources opened with the native API rather than as C handles could just be ignored when forking as those would not be used in POSIX code anyway.

The paper gives a stronger case for removing fork() than I can reproduce from memory. The argument involves a number of relatively unique resource-sharing demands that fork() imposes among others. Even if you bolt it on afterward, the demands have impacts they decry, though maybe you wouldn't regard as significant. The paper even discusses a case, k42, where it was bolted on afterward and the negative impacts it had on it.

[Solar]

FWIW, AmigaOS had a rather complete POSIX layer, ixemul library. The one thing that wasn't possible to properly emulate was fork(). Most "Amiga ports" of POSIX software consisted in replacing fork() calls with something else (and convincing upstream to accept the patch)...

[nyc]

FWIW, AmigaOS had a rather complete POSIX layer, ixemul library. The one thing that wasn't possible to properly emulate was fork(). Most "Amiga ports" of POSIX software consisted in replacing fork() calls with something else (and convincing upstream to accept the patch)...

That was in some respects a limitation in only having a single address space. Not having a potential COW sharing group of fork()'s between every pair of new address spaces created by exec()'s is a very different sort of invariant from such a serious limitation in process isolation as lacking multiple address spaces. I'm buried enough in Unix spaces that I can't really give a good example of a kernel that has refused to support fork(); even Windows NT has adopted something akin to fork() for POSIX compatibility. I'm not sure about research kernels because they, too, often compromise to POSIX for the sake of getting a user application base.

[Solar]

I'd rather put it on it's head, for the sake of this argument: fork() makes very specific demands on how the OS manages its memory / memory spaces. And when a huge percentage of fork() uses is just to immediately follow up with exec(), or because the programmer hasn't gotten the hang of threads yet, that makes fork() the crutch in my book, not the OS not supporting it.

A lot of POSIX is quite fine as a basic foundation. When it doesn't matter either way, go with POSIX instead of rolling your own. But not every single thing in POSIX is necessarily a good idea. So if you know what the problem with a particular corner of POSIX is, you are absolutely positive you've got a better approach to it, and you can live with the limited portability of the plethora of OSS out there resulting from that deviation, by all means implement it that way.

[Korona]

I don't think implementing fork by itself is so terrible, it's CoW that is annoying (or rather, it's interaction with eviction, locking and TLB shootdown. And you probably want CoW even without fork, e.g. to implement texture buffers that transparently reside on the GPU or CPU (this is what mainstream OSes do to share the GPU among processes).

[Solar]

...and what if you cannot, or do not want to, include address virtualization? Not all the systems of the world are desktops or servers. And fork() / COW becomes damn hard to do if you're working with physical addresses.

[eekee]

Indeed. ucLinux -- Linux for systems without MMU -- didn't have fork() if I remember right. (I'm pretty sure I do.)

I'm surprised to find Minix has fork(). That page is for Minix 2.0.0. They didn't start using the MMU until after 3.0. I wonder if they copy the entire process memory?

I wonder what early Unix did.

[Korona]

...and what if you cannot, or do not want to, include address virtualization? Not all the systems of the world are desktops or servers. And fork() / COW becomes damn hard to do if you're working with physical addresses.

... then you're a very specialized OS, probably not targeting the desktop, server or mobile market. You probably do not have any graphics at all (embedded) and/or only run a single task (game consoles, but is that still true these days?) and so the recommendation does not apply to you.

[eekee]

... then you're a very specialized OS, probably not targeting the desktop, server or mobile market. You probably do not have any graphics at all (embedded) and/or only run a single task (game consoles, but is that still true these days?) and so the recommendation does not apply to you.

I don't want to disagree with this when I think about it practically, considering modern hardware, but my inner rebel wants to spray-paint "Amiga" all over it.

[Qbyte]

...and what if you cannot, or do not want to, include address virtualization? Not all the systems of the world are desktops or servers. And fork() / COW becomes damn hard to do if you're working with physical addresses.

... then you're a very specialized OS, probably not targeting the desktop, server or mobile market. You probably do not have any graphics at all (embedded) and/or only run a single task (game consoles, but is that still true these days?) and so the recommendation does not apply to you.

Not neccessarily! Single Address Space Operating System designs, for instance, deliberately reject address virtualization in favor of granting processes direct access to regions of physical memory, which now makes perfect sense in the 64-bit era and has many advantages over conventional designs.

[Korona]

If you disregard spectre.

My opinion on virtual memory actually shifted into the other direction. Ten years ago I would have agreed with you (and indeed, I have a managed OS based in an in-kernel JIT on Google Code). Since then, I actually learned to like virtual memory; it enables so many useful things that stretch well beyond process isolation. Resource sharing on GPUs and accelerators, VM migration, I/O isolation via VT-d, really fast specialized userspace memory allocators, ...

[nullplan]

Most importantly, it decreases fragmentation losses. Some time ago at work we had a system running with OS-9 (no virtual memory). On the system there were only 5MB of RAM still free, but that wasn't contiguous. There was a 3MB chunk here and a 2MB chunk there. Then a process wanted to allocate 4MB. It was denied. With virtual memory, this wouldn't have happened.

OK, it turned out, with good software engineering this wouldn't have happened, either, since the 4MB allocation was only needed to load a file into memory en bloc, and we could have done what was needed in another way needing less memory, but sometimes algorithms legitimately need a lot of space.

[bzt]

I'm surprised to find Minix has fork(). That page is for Minix 2.0.0. They didn't start using the MMU until after 3.0. I wonder if they copy the entire process memory?

Not all of it, just the data and stack segments. http://www.minix3.org/doc/AppendixB.pdf page 744, function do_fork(). Sorry it's pdf, ridiculous how difficult it is to find old Minix source code online (not tarballs). I was always redirected somehow to the Minix3 source...

I wonder what early Unix did.

Same, copied the segments (if you consider v5 early. The first edition is written in PDP Assembly, not C, so there's not much point in linking that). https://github.com/dspinellis/unix-hist ... slp.c#L298. FYI, this is the same file with the famous "You are not expected to understand this." comment in unix-v6 btw

Cheers,
bzt