OSDev.org

Hi,

It's possible to get GRUB to load multiple files rather than just a kernel. For example, it could load 22 files in addition to the multi-boot compliant "intermediate code", where the intermediate code does any number of things before starting a kernel.

"GRUB starts the kernel" is not something that is required by GRUB - many alternatives are possible while still using GRUB and being multi-boot compliant (i.e. not using GRUB as a mere chain loader). Unfortunately, when reading GRUB's manuals "GRUB starts the kernel" is what most people assume - probably because of the terminology used in the manual, but also because there's nothing in the manual that directly suggests any alternative.


Cheers,

Brendan

Brendan wrote: It's possible to get GRUB to load multiple files rather than just a kernel. For example, it could load 22 files in addition to the multi-boot compliant "intermediate code", where the intermediate code does any number of things before starting a kernel.

The problem here is (IMO again ) that GRUB is really useful only when you use a common (GRUB-supported) filesystem, and probably offer the choice between several other (GRUB-supported too) fs's without needing to redo the bootloader for every single one (even though a good modular design should make this manageable). When your OS can benefit from loading modules (exchangeable, boot-time loaded drivers or kernel images, intermediate code for switching to long mode, intermediate code for relocating/linking the binary files, setting up paging....), your own bootloader should support this function anyway.

But as soon as your own filesystem comes into the game, you'll have at least to write your own mini-fs driver for GRUB...

I hope that I don't just repeat old arguments here.. I'll better come to an end.

So to finish my argumentation - I also think that it's OK to use GRUB, even from the beginning on, as long as it serves your needs, and you still know _something_ about what is going on behind the scenes when GRUB loads your code. (That there is a real mode, and that there are BIOS services...these things).

cheers Joe

JoeKayzA wrote: But as soon as your own filesystem comes into the game, you'll have at least to write your own mini-fs driver for GRUB...

Still easier than reimplementing the whole thing just as to support YourFS (and not the others)...

OK, I rest my case.

Why designing an own fs anyway, if there are enough good ones to use outta there? No need to trouble ppl more than neccessary.

Still easier than reimplementing the whole thing...

The thing is that just becasue you make your own bootloader doesn't mean that it must have all GRUB's functions.
For newbies, writing a simple bootsector that loads a couple of sectors, set pmode and jumps to it will be alot easier then you might think, and give good asm practice.
Well, I'll quit here.. No need to reply since I already know that you disagree..

@bubach: Tz. how dare you to even *assume* what I am thinking.

It's au contraire - I think you've a valid point. Playing with boot sector code has quite something for it. One just needs to draw some borders about how fare one wants to go with the stuff.

beyond infinity wrote: Why designing an own fs anyway, if there are enough good ones to use outta there? No need to trouble ppl more than neccessary.

Well, when I design my own fs for my OS, I don't think that I trouble anyone else - that's probably because no one will ever get his/her hands on the thing. No, honestly, I got your point. [Is scho recht!]

btw, this sounds a bit like a starting flamewar...

@Solar: OK, I reatreat ::) .

cheers Joe

@joekayza:
[Heast, oida, schau i so aus ois ob i do midn feia ummanaundschmeissn tat? *grummel*]

There's really no need to start a flamewar. *gg* I'm just putting things straight 'n' direct. No need to use fancy words in order to belittle what is to be told.

beyond infinity wrote: [Heast, oida, schau i so aus ois ob i do midn feia ummanaundschmeissn tat? *grummel*]

Translation:

H?r zu, Alter, seh ich so aus als ob ich mit Feuer um mich schmei?en w?rde?

("Listen, old chap, do I look like I would be throwing with fire?")

@ Joekayza, beyond_infinity:

Push your dialect a little further and I declare you no longer belonging to the German language family.

@solar: It's not as if I can draw Viennese dialect any farther. After all I'm not Mundl. *rofl* We won't go meschugge, I promise.

Brendan wrote: It's possible to get GRUB to load multiple files rather than just a kernel. For example, it could load 22 files in addition to the multi-boot compliant "intermediate code", where the intermediate code does any number of things before starting a kernel.

Yep. That's something that will get common in a microkernel environment: the bootloader will launch a "system starter" that later prepare things, initializes the microkernel, fork processes, launch servers and then gets out of the way. You can design that as multiple separate stuff or as an executable that contains several "sections": one for initializing code & data, one for the microkernel proper, etc.

BTW, can grub let you start a couple of real-mode stuff before it runs your protected mode kernel too ? That'd be interresting to gather informations GRUB does not provide (no example right now, because i don't know whether it reports BIOS ACPI stuff, etc)

@with or without YourFS ...

- it's been common for systems to have a "lightweight" version of the FS for bootstrap, for years now. So you could well leave everything GRUB needs to access in a FAT/ext2/whatever partition and put the rest using your own design ...

Pype.Clicker wrote: BTW, can grub let you start a couple of real-mode stuff before it runs your protected mode kernel too ?

Not to my knowledge, at least not without tinkering with its internals. Multiboot specification defines hand-over machine state as:

A20 gate
Must be enabled.

CR0
Bit 31 (PG) must be cleared. Bit 0 (PE) must be set. Other bits are all undefined.

EFLAGS
Bit 17 (VM) must be cleared. Bit 9 (IF) must be cleared. Other bits are all undefined.

If you want real mode, you write your real mode code into a file and have GRUB chainload it. That, however, means you don't get module loading support (as that requires a multiboot kernel to be loaded).

All this being GRUB "legacy" information, mind you. They're in the process of re-making everything in GRUB 2, but fail on being clear about anything as far as I am concerned.

Solar wrote: If you want real mode, you write your real mode code into a file and have GRUB chainload it. That, however, means you don't get module loading support (as that requires a multiboot kernel to be loaded).

...or use an intermediary code file that switches back to realmode and then executes whatever you need. This would then go into the 'kernel=' line of GRUB, all the other (realmode) code should then go into a module, for the sake of clean design. This would save you from writing filesystem and boot-device detection code, but it sounds like unneccesary complexity to me. Mainly because you'd have to copy all the realmode modules down under the 1MB-border. They really should add an option to the multiboot standard that lets you choose the mode of operation. (maybe a flag in the multiboot header, 'realmode', 'protected mode' or 'long mode') Maybe they consider such a thing already for GRUB 2, I did not yet have a look at it.

@beyond infinity: I didn't mean flamewar in the sense that you used bad language, more that we are spinning around the same arguments and no one wants to move a step. This could lead to a flamewar.

@Solar: Have you ever listened to a Vorarlberger? That's no more German, in my opinion!

cheers Joe

beyond infinity wrote: Why designing an own fs anyway, if there are enough good ones to use outta there? No need to trouble ppl more than neccessary.

If there were enough good ones to use outta there, I wouldn't design my own FS.