OSDev.org

Linking the kernel to the same addresses that userspace programs use is probably a bad idea.

It is very very difficult to compile a kernel "like a normal program", you will always want a linker script (and if you don't have one, you will end up with a kludge-y inefficient kernel).

As Combuster said, write your kernel to be multiboot compatible, it'll save you a world of pain.

Kevin wrote:Linking the kernel to the same addresses that userspace programs use is probably a bad idea.

I'm not doing that. I'm just making the kernel use a standard program format instead of custom sections. Linker scripts are not portable, they're specific to GNU binutils.

thepowersgang wrote:It is very very difficult to compile a kernel "like a normal program", you will always want a linker script (and if you don't have one, you will end up with a kludge-y inefficient kernel).

Is there any evidence supporting this claim?

thepowersgang wrote:As Combuster said, write your kernel to be multiboot compatible, it'll save you a world of pain.

I am making the kernel multiboot compatible, I'm just moving the bootstrap for it to the second stage loader instead of linking it into the kernel itself. Not sure why people are making such a big deal out of it. It's not like the kernel will constantly be jumping into and out of it. It's a 1-time thing.

Okay, I'll try to sum up my thoughts here:

Linker scripts are ABI specific and potentially work with other linkers, if they support that interface, otherwise you just gotta translate it into something equivalent for that linker. They're good, I think (a little torn myself on them, but it's my recommendation for conservative reasons), so do use them.

Kernels are not user programs. It's really that simple root cause why they aren't built like user programs. On many platforms, the kernel needs special compile time options, such as on -mno-red-zone on x86_64 to disable the red zone. Or perhaps disabling SSE and floating point stuff if you don't want the kernel to trash userland registers. Or perhaps stack smashing protection must be disabled (I do support that in my kernel though). The proper abstraction is that they are distinct. It's by chance if they're built the same way.

This idea is crazy because you're spending a lot of time doing something in an unnatural fashion (being loaded in protected mode, just to return to real mode), might not even be feasable due to a potential loss of information (MBRs have special registers set by the previous loader to tell what device is booted and such), but ultimately it's because you're spending a lot of time reinventing something poorly that gives absolutely no advantages over just multibooting your kernel directly. This approach is probably fragile, worthless, and really, you'll just waste a lot of effort on this.

These are my experiences and I suggest you discard this project and head straight for multiboot kernel land directly, or really write your own full bootloader. I also suggest you treat it as a significant hint when several established osdevers seriously questions your methods and opinions, statistics are in their favor of their being right (but doesn't prove we are, perhaps you are the sane one). Please prove me wrong if you can pull this off and it is better, but I'm not betting on it.

sortie wrote:Kernels are not user programs.

I just stated that I'm not making a user program. I'm just storing it in a standard format like elf with the defacto text, data, rodata, and bss sections. No sorcery.

sortie wrote:This idea is crazy because you're spending a lot of time doing something in an unnatural fashion (being loaded in protected mode, just to return to real mode), might not even be feasable due to a potential loss of information (MBRs have special registers set by the previous loader to tell what device is booted and such), but ultimately it's because you're spending a lot of time reinventing something poorly that gives absolutely no advantages over just multibooting your kernel directly. This approach is probably fragile, worthless, and really, you'll just waste a lot of effort on this.

I'm creating a second stage multiboot compatible loader with 2 entrypoints allowing it to be easily called from both realmode and protected mode. I don't like having GRUB crammed down my throat, but I don't want to enforce my conventions on others so I found a compromise.

sortie wrote:These are my experiences and I suggest you discard this project and head straight for multiboot kernel land directly, or really write your own full bootloader. I also suggest you treat it as a significant hint when several established osdevers seriously questions your methods and opinions, statistics are in their favor of their being right (but doesn't prove we are, perhaps you are the sane one). Please prove me wrong if you can pull this off and it is better, but I'm not betting on it.

I've got the mind of a hacker. I prefer to take the road less travelled by and find alternative ways of doing things that few people have thought of. It doesn't matter to me if my techniques are more or less efficient. I just like having the satisfaction of knowing what makes things tick and how to exploit them in unique ways.

There's nothing wrong with having the mind of a hacker, wanting to know how things work, and wanting to overthrow the established order. But when you ask people how to do that, because you don't know, you shouldn't be surprised if they come back and say "that's not a good idea". You don't have to agree with them, and there's no reason why you should, but it can be a bit tiresome when you disagree with that advice and argue with those trying to help you.

If you want to do things your own way, and everyone else disagrees with you, then it may be more politic to go and research it for yourself rather than arguing the point.

SoulofDeity wrote:I don't like having GRUB crammed down my throat, but I don't want to enforce my conventions on others so I found a compromise.

That compromise is called chainloading. All you're really doing is reimplementing what GRUB already gives you with chainloading, given that you plan to write the lightweight IPL anyway.

SoulofDeity wrote:

sortie wrote:Kernels are not user programs.

I just stated that I'm not making a user program. I'm just storing it in a standard format like elf with the defacto text, data, rodata, and bss sections. No sorcery.

You forgot to read what I was saying. I was responding to:

SoulofDeity wrote:I will be doing that. What I'm trying to avoid is having to use linker scripts or writing stubs. Inline assembly I don't mind, I just want to be able to build the kernel as you would a normal program.

My point is that kernels are not user programs, therefore might be built another way, and this is usually the case, so this is not a good reason to get rid of linker scripts. ELF is just fine, also for kernels, I agree.

SoulofDeity wrote:I'm creating a second stage multiboot compatible loader with 2 entrypoints allowing it to be easily called from both realmode and protected mode. I don't like having GRUB crammed down my throat, but I don't want to enforce my conventions on others so I found a compromise.

Multiboot doesn't require GRUB. It's a standard. Other bootloaders support multiboot too. A custom bootloader could implement it too. Additionally:

• In any circumstance where the user can multiboot your special multiboot-bootloader, the user could just have chain loaded your bootloader directly instead, and it would probably work better and be less effort.
• In any circumstance where the user can multiboot your special multiboot-bootloader, and your real kernel is also multiboot, the user could just have multibooted the real kernel directly.

As such, the way to save effort is just to use an existing bootloader to load the real kernel, or to write a custom bootloader in the conventional manner. I see no advantages of this approach that the conventional chain loading approach doesn't have, and I see a number of potential issues that makes this approach fragile.

sortie wrote:I've got the mind of a hacker. I prefer to take the road less travelled by and find alternative ways of doing things that few people have thought of. It doesn't matter to me if my techniques are more or less efficient. I just like having the satisfaction of knowing what makes things tick and how to exploit them in unique ways.

Note that exploiting how things work is bad. It's usually trouble. I very much prefer having things work as designed.

Feel free to be different for the sake of it. But do analyse whether what you do makes sense and whether it's a good solution - and whether other solutions are better. It's easy to make unconventional decisions that cause more trouble than they're worth. If you take mysterious approaches to things, with your hacker mind, all you learn is about mysterious approaches and how they work, not how things are actually serious done. But that's okay, it's your decision what you osdev.

That said, I think standard disclaimer applies and my advise isn't really applicable to you. I'll stop making suggestions.

You know, this is kind of getting ridiculous. I don't feel like debating this crap. You tell me to feel free to do things in my own way, but every time I try to, you or someone else gets their panties in a wad. It would be nice to have actual constructive criticism for a change.

I created this topic to ask how to return to real mode. I didn't need you to come here and tell me I'm crazy and don't know what I'm doing in hopes of starting a cross-thread flame war.

Constructive criticism:

1. Be prepared to do your own research, particularly if you are going to swim against the tide.

2. Don't throw a paddy every time someone disagrees with your radical thoughts.

3. Argue from sound knowledge. Don't pretend knowledge that you evidently don't have. Don't imagine that you know everything better than anyone else.

4. Re-read Sortie's last post, this time with a little humility. It contains some excellent advice.

5. If you are too proud to do 1-4 then consider whether an open form like this is the best place to present your thoughts. A blog, that you can control, might suit you better.

Seriously, iansjack, just f#*% off all already. You've been chasing me around this forum for the past few days trying to pick apart everything I say and prove I'm an imbecile. You even went out of your way to download a piece of software you've never even used before just to prove my statements about it wrong. Frankly I could care less about your insults and opinions.

I should have added:

6. Don't throw insults at other forum members, however much they bug you. It is unlikely to be productive.

iansjack wrote:I should have added:

6. Don't throw insults at other forum members, however much they bug you. It is unlikely to be productive.

You say that after literally making a list of 5 things to insult my intelligence. Like I said before, you're full of ****, and I could care less about your insults and opinions.

This has degenerated into insult slinging.

The original question has been answered (the Intel manuals cover how to return to real mode), and advice has been given on better approaches (making the kernel multiboot-comptaible, getting the original loader to load everything for you).

Locking.