These days brk and sbrk have fallen from grace (and I think even some Unix-likes no longer provide them as general mechanisms, at least I don't think macOS does) - mmap is usually favoured.
Notwithstanding that most kernels today are written almost entirely in C anyway, you'll see learn a great deal about memory allocation by inspecting malloc().
The usual division of labour in most operating systems is the kernel manages the virtual memory and physical pages and provides a mechanism for coarse page-aligned allocation of virtual address for userland. These coarse mappings userland (malloc or something else) is responsible for carving up, and in that is much design space. Just look at mimalloc for example.
The kernel's own page allocation is often very simple (many get by with a simple freelist, some use buddies.) The allocators for the kernel's own datastructures are usually relatively simple at least conceptually. Bonwick explains the slab allocator - the almost universally acknowledged queen of all kernel memory allocators and mother of those of Linux, BSD, and beyond - in a 12-page paper.
As for the firmware there's basically nothing of an ongoing role for it after the kernel is in charge. Its role is limited for the most part to providing the kernel with a map of the physical addres space.
By reading malloc() you will not learn everything about allocation - that is a problem that spans multiple layers - but you will certainly learn a lot about it. To call it a mere wrapper is not reasonable.
It wouldn't surprise me if I learned that the vast majority of programming globally is in languages like Visual Basic or PHP that are utterly unfashionable on a board like this, but still make the world go round.
It's a bit hard to comprehend that's reality to be honest.
But I could see that it could be the case from the fact that old industrial factories or old corporates would still run with what works for them.
It's a completely uncontroversial fact that NT does implement fork(). Turn to page 183 of Helen Custer's "Inside Windows NT" and you will read about it.
The principle of a paging system is that main memory is just a cache for secondary memory, and the concept of "free memory" ideally rather means something like "memory that can be quickly reclaimed for another purpose". Sometimes anonymous memory will be of less us occupying main memory at some given time than would be letting cached file contents take their place.
You've described what the purpose of a swapfile is – thanks? My argument is simply that you don't need a swapfile with enough real memory; that swapfiles can unnecessarily shorten the lives of SSDs, entirely unnecessarily.
----
>I have 20GB of RAM free (me)
>>~need to have quick access to main memory
>I have 20GB of RAM free (still me)
>>~yeah but "quickly reclaimed for another purpose"
>I have 20GB of RAM free (!m!e!)
//of//32GB//ttl//
----
In linuxland, I'd just type `sudo swapoff -a` and be done with it. That machine has 96GB of RAM, so it would have ~84GB of RAM free (if, hypothetically, the same hardare/configuration were operating that system).
Does. not. need. a swapfile.
The operating system, during bootup, should think "hey I have dozens of gigabytes of RAM, won't be needing any swapfiles" – behind the scenes and without input.
The general principle is that what is involved in paging should not be paged itself. Wiring the memory of that whole daemon is then a trivial solution to the problem.
Plan 9 implements some sort of "everything has a directory entry" concept. Sockets are files already in Unix. "Everything is a file" in Unix means they have a uniform treatment as file descriptors. Its perfection is probably in Capsicum where when you create a new process, you get a process file descriptor referring to it instead of a PID.
As much as I like bsd I think the socket interface is their biggest failure, don't get me wrong, the socket interface is not bad, it is an amazing accomplishment that most of the internet is based on. The reason I regard it as a failure is because it is so close but not quite touching. A core unix idea is to have a single namespace registry and a simple universal api(open, seek, read, write, close) to access resources on this registry. and you can tell the bsd socket team was trying(like I said it's close) but they failed to close the loop and shipped an api that did not match the core unix api.
And for free, a rant, I think this is why Microsoft's registry is so bad. On paper it sounds great "a single place to put all your config" I could totally sell it. But in practice it is miserable to use. When proposed nobody said "we already have a hierarchical namespace where all our config can go and it already has pretty great tooling, lets just make it better" so they invented a custom one that required custom special access patterns and custom special tooling and custom special api's, and... it sort of sucks to use. I guess in their defense they were not fully onboard the idea that you could have one tree(they liked their many trees A: B: C:)
You do read sockets with read/write, that's the point of saying 'everything is a file'. You can basically can do read/write/close on things that are a socket.
Yeah, I probably went too far in saying it's just the userland, but I'll insist it's more complicated than saying it was based on 4.4BSD-Lite2. I haven't done a proper deep dive yet, but I can tell that it wasn't strictly based on the Lite2 release. Take a look at XNU 123.5's (OS X 10.0) kern/tty.c:
You'll also see the source has been reorganized, with e.g. the VFS source being regrouped into bsd/vfs, instead of being left in bsd/kern. This coincidentally mirrors how OSF/1 was organized (no other source relation though, just an interesting observation):
This file had to be reimplemented by all of the BSDs. In this case, this version appears distinct from the FreeBSD and NetBSD versions I can find.
If you grep around for the `NeXT` ifndef/ifdefs in XNU, too, you'll see some code of which some appears to have been copied/adapted from the NeXT source tree, itself derived from Mach/CMU sources. (and 4.3BSD ;-)
I say all this to draw attention to the ways XNU differs from BSD, which is pretty interesting, at least to me.
reply