OSDev.org

BTW, There is no paging in these micro kernels. The GDT and IDT setup is same for both the kernels.

JJeronimo wrote:This could include a special entry point for hot boots (or a special boot-time parameter so that the kernel knows it's being executed from inside a running system), that would skip paging and memory initialization. Additional information could also be passed, such as addresses for kernel structures and stuff alike.
.......................
The problem is that some drivers may need to re-initialize it's hardware, and others may not need. Also, the same problem arises if you change e.g. the memory management structure's layout. The trick could be controlling this in a drive-by-drive fashion, and forbidding "hot swaps" if a critical kernel structure was modified.
JJ

I forgot to mention that this is a really tiny micro-kernel that wants to get launched. There is NO PAGING in both the kernels. It is not going to need any extra drivers. I'm using only serial port in port-io mode. I could hard-code all the addresses if that would help.

inflater wrote: Who cares about linux?

Frankly inflater, this is not only extremely off-topic and rude but extremely unhelpful, too. I was merely directing the reader to use linux's source code(which is FOSS) to help him to implement the functionality that he is asking for. This is a perfectly valid answer as linux does have the functionality he is asking for.

I was merely directing the reader to use linux's source code(which is FOSS)

Oh. You don't know the answer to his question directly, but you say to him RTFM the Linux source code?... That's sure helpful.

...to help him to implement the functionality that he is asking for.

Yes, if he would build his API/environment suitable for the kexec function. I surely wouldn't do that.

This is a perfectly valid answer as linux does have the functionality he is asking for.

As stated in the second paragraph. If you don't know the answer to his question, don't post since we are in the OS development section and not General ramblings.

Regards
inflater

Hi,

Just a quick note...

I'm planning something slightly similar. My approach will be to define a specific boot state, where all boot loaders do what-ever is necessary to put the computer into this boot state. The boot state includes loading a boot image into RAM, gathering data (ACPI/MPS tables, memory/physical address space detection, etc), setting a default video mode, ensuring all CPUs are in the right operating modes, etc.

The kernel would be able to put the computer into this same boot state during shutdown; so that a "full" reboot (where all running software including the kernel can be replaced) can be done without a hardware reset, without BIOS, etc.

This means all device drivers would need to re-initialize and all kernel data structures would need to be rebuilt, but also means that the stability of the OS being booted doesn't depend on previous device drivers or previous device states, or previous kernel data structures.


Cheers,

Brendan

Slightly OT...

Yes, if he would build his API/environment suitable for the kexec function.

Why do you think he needs to build his API/environment suitable for the kexec function to just see how linux has implemented kexec? Do you mean you have to copy code once you've seen it?

As stated in the second paragraph. If you don't know the answer to his question, don't post since we are in the OS development section and not General ramblings.

As a reader of this forum, I fear I prefer posts suggesting what good implementations there exist of kexec then one's manifestoes of his dislikes.

to just see how linux has implemented kexec?

Well, if he only wants to see how linux has done that, you're right, but what's that good for?

I prefer posts suggesting what good implementations there exist of kexec

Good luck looking into linux's source code

Brendan wrote:Hi,
I'm planning something slightly similar............

The kernel would be able to put the computer into this same boot state during shutdown; so that a "full" reboot (where all running software including the kernel can be replaced) can be done without a hardware reset, without BIOS, etc.
Brendan

I do not want to reboot, but just discard the previous kernel and start the new one. Trying to get some good info on kexec, but all I get is just some vague stuff.

Looking at good code generally helps, for one thing.. there is a lot of habits that you go with an "oooh that helps readability a lot" which you can pick up when analysing well-written code. Reading linux source code shouldn't be that bad, there are developers who do it regularly

Hi,

sawdust wrote:

Brendan wrote:The kernel would be able to put the computer into this same boot state during shutdown; so that a "full" reboot (where all running software including the kernel can be replaced) can be done without a hardware reset, without BIOS, etc.

I do not want to reboot, but just discard the previous kernel and start the new one. Trying to get some good info on kexec, but all I get is just some vague stuff.

AFAIK Linux does something similar - it shuts down the existing kernel, prepares the system to start another kernel then starts another kernel; where the new kernel being started doesn't know it wasn't booted by a normal boot loader and reinitializes everything. The only difference here is that my "boot state" is different from Linux's "boot state".

For more information on how kexec works in Linux, see this web page.

Think of it like this. There's only 3 reasons to reboot: to start a completely different OS, to upgrade software that can't be upgraded without a reboot, and to recover from crashes.

If you're starting a completely different OS then you need a full reset.

If you're rebooting to upgrade software, then increasing the amount of "old state" that is re-used will also increase the chance that you need to do a full reset. For example, if the new kernel uses a slightly different data structure/s, then passing the old kernel's obsolete data structures to the new kernel won't help.

If you're rebooting to recover from crashes, then increasing the amount of "old state" that is re-used will also increase the chance that you need to do a full reset. For example, if the old kernel crashes due to messed up kernel data structure/s, then passing the old kernel's messed up data structures to the new kernel won't help.


Cheers,

Brendan

inflater wrote: Well, if he only wants to see how linux has done that, you're right, but what's that good for?

When you see how a well-reputed os has done something that you want to implement in your os. Seeing the mechanism by which that os has done something is usually a good way to start the implementation of that same mechanism in your own os.

inflater wrote: Good luck looking into linux's source code

This is just a cheap shot at linux.

Somehow, I have the feeling that inflater would not be so upset if I had directed the OP to look into the source code of Microsoft Windows.

iammisc wrote:This is just a cheap shot at linux.

Somehow, I have the feeling that inflater would not be so upset if I had directed the OP to look into the source code of Microsoft Windows.

No need to get offended so quickly - perhaps he's just referring to complexity of the sources for such a large project. I've had a look at Linux source code before and some of it is a bit of a headache - I don't think that the source for Windows would be any better but have no way of proving this

Cheers,
Adam

AJ wrote:

iammisc wrote:This is just a cheap shot at linux.

Somehow, I have the feeling that inflater would not be so upset if I had directed the OP to look into the source code of Microsoft Windows.

No need to get offended so quickly - perhaps he's just referring to complexity of the sources for such a large project. I've had a look at Linux source code before and some of it is a bit of a headache - I don't think that the source for Windows would be any better but have no way of proving this

Cheers,
Adam

Let's be fair, the linux source code is absolutely horrendous in places. Uncommented chunks of code with cryptic names and spaghetti code all over the shop... Look into the BSD sources for a comparison.

I've had a look at Linux source code before and some of it is a bit of a headache - I don't think that the source for Windows would be any better but have no way of proving this

Linux's TCP code knocked me down There were comments, but not about what the functions were supposed to do

Look into the BSD sources for a comparison.

They're better? Gonna take a look:D

Hi,

Brendan wrote:[...]
My approach will be to define a specific boot state, where all boot loaders do what-ever is necessary to put the computer into this boot state. The boot state includes loading a boot image into RAM, gathering data (ACPI/MPS tables, memory/physical address space detection, etc), setting a default video mode, ensuring all CPUs are in the right operating modes, etc.[...]

Perhaps use the same state as multiboot compliant bootloaders put the system in (or bootloaders compliant to some other standard)?

Or perhaps some form of negotiation about the state to leave the machine in:
The first OS receives data about the desired state of the second OS and it puts the machine in this state. You could encode the information about the desired state in the second kernel's image or pass it at run-time to the kernel exec function. This would mean that you have to define several specific boot states.

Brendan wrote:[...], but also means that the stability of the OS being booted doesn't depend on previous device drivers or previous device states, or previous kernel data structures.

What about the risk of broken/crashed drivers in the first OS, which do not properly deinitialise the devices?
Or do I assume a too large amount of "old state" that is reused?
I guess that dynamically determining the amount of "old state" to reuse, depending on crashes, etc. would border on Turing's Halting Problem, correct?

Cheers,
Kasper