Managing exec-persistent memory

[NickJohnson]

In order to implement various structures, like the file descriptor table (I don't manage this in the kernel), environment variables, and argument list, I have a chunk of user memory (from 0xC0000000 to 0xE0000000) that persists through process execution; part of this is also used for execution itself: to hold the executable image. I've been assigning fixed addresses for these structures, but that seems kind of hacky, so I tried to implement a simple heap to organize it. Unfortunately, that becomes a nightmare because the heap structures also have to be in the persistent area, so they have to have static addresses, and global pointers cannot be, so they have to be initialized and synchronized wherever they are. For a bit I was trying to have a separate ELF segment instead of a heap, but I realized that would break with differently-compiled executables because they may interpret the space differently.

Does anyone have a better idea for managing this space? I'm out of ideas.

[Gigasoft]

User programs shouldn't access this directly. Instead, one usually uses an API implemented by a system library. This library can manage everything including heaps. It should always be loaded, so that it will remain if the main executable is unloaded and another main executable is started in the same process.

[NickJohnson]

User programs shouldn't access this directly. Instead, one usually uses an API implemented by a system library. This library can manage everything including heaps. It should always be loaded, so that it will remain if the main executable is unloaded and another main executable is started in the same process.

Are you talking about moving it into the C library (which is already how it works), or moving it into the kernel? By user programs, I meant any code that is not in the kernel, including all libraries.

Also, in case it was unclear, I'm using a UNIX-style fork/exec model here.

[Gigasoft]

Well, yeah. For the file descriptors, there is no problem, since they are internal to the C library. For data passed from the kernel to the C library, the kernel could reserve the necessary virtual memory for it, assign physical pages, fill in the information and place pointers to the various data structures in a master table located at a fixed address. There won't be a problem with differently compiled executables accessing this, because the installed C library will always match the system version.

[NickJohnson]

I guess a "master table" design would work: I would just have to keep the offsets consistent through C library versions to not break compatibility. I still have reservations about having the kernel manage a user heap: it's a lot of policy to add to a microkernel.

[gerryg400]

I still have reservations about having the kernel manage a user heap: it's a lot of policy to add to a microkernel.

I guess this was my motivation for moving process memory management out of the kernel. Once fork and exec leave the kernel all that 'guilt' disappears!

[Owen]

Numbered (POSIX-style) file descriptors are really a concern for the POSIX subsystem, unless your kernel has a concept which is sufficiently analogous (such as message ports). In that case, they should probably be memorized in some kind of POSIX daemon; How the POSIX emulation layer interacts with them is up to you.

Environment variables should be maintained by some daemon also; which daemon, your call.

Memory should then become the process' responsibility, because exec asks another daemon to clear out the process image and replace it.

[NickJohnson]

Numbered (POSIX-style) file descriptors are really a concern for the POSIX subsystem, unless your kernel has a concept which is sufficiently analogous (such as message ports). In that case, they should probably be memorized in some kind of POSIX daemon; How the POSIX emulation layer interacts with them is up to you.

I use numbered file descriptors for low-level I/O operations in my C library, just because it's a nice design, not because I need it to be POSIX-compliant. Whether they are numbers or pointers, they still have to be persistent.

Environment variables should be maintained by some daemon also; which daemon, your call.

I do have a daemon that could also manage environment variables (it currently manages process permissions), but wouldn't that have a lot of overhead? I could just use the persistent memory block, provided that I can manage it properly, which is my issue. I just need to be able to manage the persistent memory, then I can store whatever I need to in it.

[Owen]

Have the daemon memory map the environment block into your process?

[NickJohnson]

Have the daemon memory map the environment block into your process?

I don't have shared memory capability in my OS (it's pure message passing), so doing that efficiently would take a lot of work. My argument is that there's no benefit to moving it into a daemon if I can properly manage the persistent memory block. I'm not looking for ways _around_ managing it.

I'm now thinking that fixed addresses may be the way to go anyway: there's a lot of virtual memory between 0xC0000000 and 0xF0000000, and not that much data needs to be persistent, so it wouldn't be too bad to waste some on reserved areas that are unused.

[Gigasoft]

If only the C library ever accesses them, there's not really a problem. There should only be one version of the C library installed an in use at any time. Or does your OS not support dynamic linking?

[NickJohnson]

It doesn't support dynamic linking yet, but even then, the C library may not be the same for all processes, right? What if a process uses static linking with a C library of a different version, or someone writes an assembly program with no C library at all?

[Gigasoft]

Anything system version dependent has to be separated out into a system library which is bundled with the system. To avoid implementing dynamic linking, you could pass a pointer to a table of entry points for the library to the program, or the location of a function which copies a number of entries from this table to an user-defined location (zero filling entries that would go past the end, or filling them with the address of a default "undefined function" handler, such as when a program is written for a newer system version).

[NickJohnson]

I'm not avoiding implementing dynamic linking, I just haven't done it yet. What I am doing is trying to make it so nothing (not even C library version) is strictly required of a userspace program for it to interpret the persistent memory. However, it seems like that is impossible without adhering to some sort of standardized fixed-address or table scheme, so I'm going with that approach.