Runtime rewriteable Kernel

[GAT]

I've done code in interpreted languages where the user can rewrite the code while it is running.
Would it be possible to do something like this for a kernel, or at least part of it?

[Love4Boobies]

I don't think you even understand your own question. Would you be willing to elaborate exactly what you mean by this?

[bluemoon]

Depends on what you meant by re-writable interpreted kernel,

1. You usually don't want a interpreted kernel for performance reason.
2. Your get your user surprised if the kernel or API has be rewritten and behalves differently.
3. At least on Intel, self-modifying code is discouraged.
4. kernel itself is a complex piece of software, having it re-written on the fly add extra complexity.
5. If the changes is so dynamic, you might eventually make your user a test pilot.

On the other hand,

6. If you meant to extend features, or add support for new hardware, it has been done by everyone, usually with modules and/or hooks.

[Love4Boobies]

Don't answer him, now he'll pretend you've answered your question in order to get away with having no clue what he's asked.

[GAT]

What I mean is having part of the kernel in something like assembler or C that won't change, and having that part of the kernel running some interpreted code for a shell or other parts of the kernel. Set up an editor in the part of the kernel that won't change, and then being able to edit the interpreted part of the kernel on the fly. I was thinking this way you could just boot up into the OS and instead of having to reboot or reload the OS when you want to change part of the kernel, you could just rewrite parts of it with the editor.

[Combuster]

You definitely want kernel modules.

Ever tried doing dynamic loading of plugins in userland?

[turdus]

Yes, it's possible.

You made my day with this answer, man!

For the OP: http://en.wikipedia.org/wiki/Von_Neumann_architecture

[DavidCooper]

What I mean is having part of the kernel in something like assembler or C that won't change, and having that part of the kernel running some interpreted code for a shell or other parts of the kernel. Set up an editor in the part of the kernel that won't change, and then being able to edit the interpreted part of the kernel on the fly. I was thinking this way you could just boot up into the OS and instead of having to reboot or reload the OS when you want to change part of the kernel, you could just rewrite parts of it with the editor.

In my OS I have two modules which are capable of loading, modifying and saving any other OS module (or application module) including each other, so I can modify any part of the OS while the OS is running. The part being modified usually isn't running at the time, and when I modify interrupt routines I can simply disable interrupts while doing so, but it is also possible to post a jump instruction into an active interrupt routine to divert it to a temporary replacement section to bypass the section that needs to be modified, and on occasions I've been able to debug interrupt code just by changing instruction bytes here and there while it's running.

So, given that all that is possible (and even practical), it should be fully possible for you to do what you describe - you'll have a core chunk of OS which you won't be able to modify while it's running, but the rest should be fully open for you to do. You may have to stop applications that are running on the machine in order to change some things, and you may have to restart some of them from scratch afterwards (it all depends on what you're changing and whether it may destabilise anything), but even that's usually better than having to reboot. I get the impression that a lot of intelligent people here don't think it's a good idea, perhaps because they think it won't save any effort or because it's too likely to cause crashes, and they might well be right - I don't know for certain because I've only ever done this with a system using direct machine code programming, so before you go ahead with your plan, you would do well to find out what their objections are, though Bluemoon's already given you some to start with (much of it probably won't apply as I don't think you're talking about ordinary users modifying anything in the kernel, but point no. 1 should be considered carefully).