Design and Implementation of an Extensible OS

[Candy]

I know i'll get a "i didn't meant to offense anyone", but you actually did. Why would we fake anything ? Don't you think at this point we've gone over the "i'll conquer the world" stuff ?

Think of it briefly: what does Linux offer ? a system where you may (if lucky) disable a set of functions and then replace it by another set of function. Jedld's solution aswell as mine focus of a no-interruption of service approach: clients of a component *do not even notice* the server changed.

If you would for instance change the way the filesystem is behaving, you'd have no other option than first unmounting all the partitions that use that filesystem. That's precisely what we want to avoid.

Why bothering ? What do you do when you want to take a break at coding and play a game ? you reboot and switch to a MS product or to a game console because it had been better tuned for gaming. What if tomorrow, by the power of hot-swappable component, you could stay on the same OS and simply switch to another set of preferences and then going back when the game is over ?

Do you have to be able to reload the module? Different modules introduce different bugs, same module with different preferences is not the same. Why not make a highly configurable module with a nice interface (that hides 90% of the options again, and renames them to nicer things) ?

And then again, changing policy does not require a reboot at all, at least for most modules. The point behind your reasoning why yours is better than personalities in modules is because you don't have to reboot to switch. The only time I'd reboot with personalities is when the one loaded has a bug, and that'd mean the taking over stuff would bug out too. Your point loses against itself.

Wouldn't that worth fighting for ?
Wouldn't that worth ... coding for ?

If I'd have to guess, I'd say you were a program for the machines

[Pype.Clicker]

well, the main concern i have about 'personalizable' modules is that they restrict yourself to what has been considered 'possible' by the module writer. This is certainly a step on the good path but it cannot cover everything.

I never said the technique was 100% fool-proof and a bad server can certainly lead to system instabilities, as well as a bad personnality in a personnalizable server. Yet if you observe that the performances for your goal are poor, you can revert to the previous component.

Now, i must admit that also plan to have a method to seal services once the system administrator decides they shouldn't be changed anymore (avoiding the overhead for checking service availability at every service call)

[ASHLEY4]

Any one who does use big word to decribe simple things is guilty.I have not seen you (Clicker) use big words,for simple thing.

And the OS your go on about, is the same OS that I'm making,It just does it in a differant way.

ASHLEY4.

[jedld]

Umm, excuse me, but what level of memory allocation are you talking about? I mean, usually there is page-allocator on the bottom. Then there's kernel malloc, then there's the virtual memory system, and then there's user level malloc or garbage collectors or whatever.

As I've said in my first statement, it is the kernel memory allocator or the kmalloc, kfree, krealloc group of functions

Now, let's take one at a time. Replacing the page-allocator on the fly is quite simple, just move all free pages from one allocator to another (in effect allocating all pages from the old allocator to the new one) and provide some interface for the new allocator to reuse any relevant data in case there's some. But then again, this level is usually just a stack of free pages, so what's the point.

I agree, but then again that's not what I'm talking about.

In kernel level malloc, one will want to redirect all the allocation to the new malloc when switching. Here we have the problem that different allocators are going to use different schemes for dividing memory, so it's non-trivial to transfer allocations from one system to another. In any case, to replace such allocator, I'd probably implement some object-system, which has an interface consisting of malloc/free/realloc equivalents, and then explicitly use one implementation using a pointer. One could define the "default" allocator, switch it on the fly, or request all kernel modules/whatever to allocate memory from the other allocator and move data over. It's not fast, but that's probably the most reasonable thing to do, if one really wants to move over.

There's a problem with this though if one allows pointers between different modules, but even then one can always add a level of indirection similar to what some compacting garbage collectors do. This takes a small performance hit though. Other possibilities include to add a lot of glue to all interfaces just to communicate memory changes, or to require all allocators to handle existing allocations of any kind gracefully, and build an interface for transferring stuff over from one to another.

My thoughts exactly, additionally we could add a malloc server which could monitor the malloc and free counts of the new mallocs and the old ones. if malloc count == free count then no one's using this malloc module and we can remove it from memory. A side effect of this would be that since we're using single virtual memory region for all malloc modules, we'd be having virtual memory holes so to speak.

Now, virtual memory allocating is a similar problem, but since we are now dealing with pages, we have same size of basic unit in every allocator, so it's just a question of building an interface for transferring allocations over from one allocator to another, and then requiring all allocators to implement this interface. If performance (of allocator changes) is not issue, then this is almost trivial, and I can't imagine anyone wanting to change all the time. If virtual memory works on process level, one can even use different allocators for different processes, although this certainly adds overhead to shared memory and copy-on-write scenarios.

I haven't gone this far in my OS yet, but you have a good point.

Finally, application-level malloc library has nothing to do with operating system kernels (as long as we have some interface to virtual memory management to request mappings for more pages).

Of course.