OSDev.org

bubach wrote: How come that the FAQ don?t have anything about setting pmode/gdt etc?
IMHO: Linking to bona fide osdev is a good thing, but shouldn?t the FAQ have atleast some basic info on this?

crc wrote: http://www.osdev.org/osfaq2/index.php/ProtectedMode tells how to set pmode IIRC. I did a quick search for info on GDT and IDT, no results came up

I agree; the FAQ should cover at least the basics of these as they are very useful. Maybe I'll add some information on them this weekend.

bubach wrote: ok, but what about a simple example?
i can?t even find a simple example of a bootsector...

a simple example bootsector that reads a couple of sectors of the floppy and maybe goes into pmode would be nice..

df wrote: coz we pretty well tell everyone to use grub instead of worrying about a bootsector.

its time to get people past the bootsector to writing a real kernel etc.

Brendan wrote: Hi,

df wrote: coz we pretty well tell everyone to use grub instead of worrying about a bootsector.

its time to get people past the bootsector to writing a real kernel etc.

I disagree - it's time to prevent people from starting a full kernel when they lack the knowledge needed to write a simple boot sector.

IMHO GRUB is a lazy mans curse rather than something that's actually useful for serious OS developers.


Cheers,

Brendan

PeaceMan wrote: I've only just started fiddling around with bootsectors and OS dev and I have to agree with Brendan:

I disagree - it's time to prevent people from starting a full kernel when they lack the knowledge needed to write a simple boot sector.

Messing around with simple bootsectors taught me things as I had to learn how to use assembler, print text (without simple headers like iostream), load sectors and enable the A20 line.

I only just enabled the A20 line this morning and it really gave me a feeling of achivement and progress.

Also, I don't like using 'black boxes' of code that I don't understand or that I couldn't write myself, as it stops me learning what it's functions are.

df wrote: thats why there is 100000 bootsectors out there and few OS's. People write a bootsector, go 'yay' and thats it.

consdier, everything you learnt in the bootsector is totally useless when applied in an os. printing text, you need a different method in pmode. reading sectors, ditto. enableing the a20, you do it once and thats it...

Brendan wrote: Hi,

df wrote: thats why there is 100000 bootsectors out there and few OS's. People write a bootsector, go 'yay' and thats it.

You'd rather see 100000 kernels with partial memory management and few OS's? Dedication is a requirement for OS dev, some people just don't have it. Perhaps if we advocated GRUB, the Linux kernel and X we'd have more OS's...

IMHO GRUB is limited, and imposes it's limitations onto the resulting OS. GRUB is good for people writing hobby OS's who are unlikely to be restricted by GRUB. For serious OS developers GRUB doesn't do much that can't be done within a week without GRUB's limitations.

It's better not to advocate anything, but rather offer possible options and the advantages/disadvantanges of each option (especially for the OS FAQ).

df wrote: consdier, everything you learnt in the bootsector is totally useless when applied in an os. printing text, you need a different method in pmode. reading sectors, ditto. enableing the a20, you do it once and thats it...

I wrote my first boot sector when I was learning 80x86 assembly over 10 years ago (before GRUB existed). Enabling A20 is a good little introduction to the keyboard controller chip, and hardware programming in general. Reading sectors via the BIOS is a good introduction to the (conceptual) physical layout of data on disks. Boot sectors are also an easy introduction to memory management (e.g. "where should I put the kernel?", and "what are segments?").

Would you consider it a good idea for a potential OS developer to have some experience writing application software before starting a kernel? Why?


Cheers,

Brendan

crc wrote:

IMHO GRUB is limited, and imposes it's limitations onto the resulting OS. GRUB is good for people writing hobby OS's who are unlikely to be restricted by GRUB. For serious OS developers GRUB doesn't do much that can't be done within a week without GRUB's limitations.

What limits are you thinking of? I'm not the biggest fan of GRUB, but it works pretty well on most of my current hardware. To be honest, my kernel isn't useable with GRUB, though I am attempting to add a GRUB-compatible wrapper (which will be 100% optional)

crc wrote:

consider, everything you learnt in the bootsector is totally useless when applied in an os.

That's not true if your OS runs in real mode

df wrote:

Brendan wrote: IMHO GRUB is limited, and imposes it's limitations onto the resulting OS. GRUB is good for people writing hobby OS's who are unlikely to be restricted by GRUB. For serious OS developers GRUB doesn't do much that can't be done within a week without GRUB's limitations.

have you seriously looked at grub? netboot support on LOTS of network cards, tftp server, native filesystems, automatic decompression, etc.

what limitations does it imply? that you cant load a kernel below 1mb? and what else???

so grub limits serious os coders.. right. grub can boot linux, freebsd, hurd, dos, windows, os/2, etc. but none of those are serious OSes eh?

so tell me what these really big grub limitation issues are?

crc wrote: I thought that you had to use chainloading to boot Windows, DOS, and OS/2 with GRUB. Am I wrong?

Brendan wrote: Hi,

crc wrote: What limits are you thinking of?

First, when I said "GRUB limits" I meant limits imposed by using GRUB as intended (in conjunction with it's multi-boot specification). Obviously these limits shouldn't apply if you're using GRUB to chain load a normal boot sector (e.g. like DOS's).

You can't have your kernel loaded into conventional memory, can't have a list of available video modes the user can choose, can't automatically have a video mode set reliably, can't automatically select the right kernel to boot from a list of possible kernels, can't boot the kernel with paging enabled, can't load several copies of the kernel into memory corresponding to several NUMA memory ranges, can't set boot options (unless you expect the user to add "command line arguments" to the kernel, which IMHO isn't very professional for OS's designed for average users), can't set the correct RTC time before boot (which is important for my OS), can't handle a custom kernel binary format or custom file system (without major hacking).

The above is just a list of reasons why my own OS can't use GRUB (rather than a list of all possible reasons).

GRUB's limitations aren't the only reason I don't like advocating GRUB. When a new OS project does start with GRUB they tend to begin with a simple kernel (elf or a.out) loaded from a standard file system into physical memory just above 1 Mb. Then they keep adding code to this simple kernel. It puts the OS developers into a certain mindset when they should be learning and making choices for themselves, and sooner or later they've got enough of the kernel done that it's too hard to change to something different (or too hard to change to something they really want after learning enough about OS development to make completely informed decisions about it).

It seems I'm not alone in thinking that GRUB is a solution to a problem no-one ever had. Let's have a look at the number of OS's that do use GRUB:
- All microsoft OS's, OS/2, SCO Unix and QNX are booted through chain loading
- GRUB has been hacked for FreeBSD, NetBSD, OpenBSD, and Linux (these OS to aren't designed for GRUB either)
- For FreeBSD it's recommended to use FreeBSD's loader instead (GRUB won't handle it's kernel parameters)
- GNU/Hurd is the only OS I know of that actually does use GRUB as intended

That's 1 OS out of all OS's I can think of (excluding some OSs that haven't been completed yet, hundreds of OS projects that died, and some that haven't died yet).

I'm not against GRUB - it's great for those who already have a firm OS design and enough knowledge to determine if it's suitable for the project or not (but IMHO it's not the best thing for people who are just starting in OS development).

crc wrote: I'm not the biggest fan of GRUB, but it works pretty well on most of my current hardware. To be honest, my kernel isn't useable with GRUB, though I am attempting to add a GRUB-compatible wrapper (which will be 100% optional)

I use GRUB to dual boot between Windows and Linux (and it does work well). I tried to get it to boot a DOS floppy via chainloading and it failed to restore the video back to text mode before booting it and also makes DOS crash somehow. I still haven't figured out if it's possible to get GRUB to do it. One of my early boot loaders (from back when I was still learning assembly) had an option to boot a floppy. All it did was load the first sector of the floppy, set some registers and jump to 0x7c0:0000 - worked perfectly on everything I tried (even booted my OS from the second floppy drive), but GRUB has trouble???

If the OS isn't designed for GRUB, people can use GRUB to chainload it (you've lost almost nothing).


Cheers,

Brendan

crc wrote: My main purpose in adding a GRUB wrapper is to make some tests easier. My current boot sector is pretty simple, but doesn't work on many computers since it uses multitrack reads. (I hope to rectify this soon) The GRUB option gives me a loader that I know works, and allows me to test the OS on more hardware. It'll also make it easier for the users who already use GRUB to boot it. On the other hand, it takes GRUB longer to load than my OS takes to be recompile itself at boot time.

I must admit, I prefer to put my kernel in the first meg of RAM, which GRUB doesn't like doing. One of my test machines only has 1MB of RAM, so GRUB is useless on it.

df wrote:

Brendan wrote: Hi,
You can't have your kernel loaded into conventional memory, can't have a list of available video modes the user can choose, can't automatically have a video mode set reliably, can't automatically select the right kernel to boot from a list of possible kernels, can't boot the kernel with paging enabled, can't load several copies of the kernel into memory corresponding to several NUMA memory ranges, can't set boot options (unless you expect the user to add "command line arguments" to the kernel, which IMHO isn't very professional for OS's designed for average users), can't set the correct RTC time before boot (which is important for my OS), can't handle a custom kernel binary format or custom file system (without major hacking).

looking at your list, i think your confused. grub is a bootloader. it loads your kernel. its not its job to act as your video driver and let you pick a graphic mode, thats your job. its not grubs job to setup page tables for you, thats your job. its not grubs job to know numa memory regions, thats your job, just like its not grubs job to init the APIC and fire each of your modules off in a thread.
its not grubs job to change RTC timer frequencies, thats your job. its nots grubs job to provide you with a list of devices in your machine. thats for you to work out.

grub loads your first stage into memory and thats it. anything more would be wrong. grub was designed to load a file from disk.

if you want all those extra features, write a 3rd stage loader that grub boots, then you can merrily go on your way and do numa multiple kernel loads etc.

thats essentially what freebsd does

For FreeBSD it's recommended to use FreeBSD's loader instead (GRUB won't handle it's kernel parameters)

that extra step is FreeBSD's BTX forth bootloader. Grub for some reason skips trying to load BTX and tries to load the freebsd kernel, when it should just load BTX.

Brendan wrote: Hi,

df wrote: looking at your list, i think your confused. grub is a bootloader. it loads your kernel. its not its job to act as your video driver and let you pick a graphic mode, thats your job. its not grubs job to setup page tables for you, thats your job. its not grubs job to know numa memory regions, thats your job, just like its not grubs job to init the APIC and fire each of your modules off in a thread.
its not grubs job to change RTC timer frequencies, thats your job. its nots grubs job to provide you with a list of devices in your machine. thats for you to work out.

grub loads your first stage into memory and thats it. anything more would be wrong. grub was designed to load a file from disk.

Unfortunately you seem unable to differentiate between OS's that boot with their own boot code, and OS that use GRUB as intended (ie. multiboot compliant OS's). The former can all boot without using GRUB, and GRUB merely imitates some of the boot that they expect (for e.g. chainloading) - I have no problems with this. For OS that use GRUB as intended my full list of limitations (and other comments) apply.

This is because GRUB (when used as intended) does NOT just load an OS's "first stage into memory and that's it". Instead it loads a kernel into memory and starts it, after enabling protected mode, detecting physical memory, detecting video BIOS and APM details, etc.

df wrote: if you want all those extra features, write a 3rd stage loader that grub boots, then you can merrily go on your way and do numa multiple kernel loads etc.

Of course - I could write a 3rd stage the reverses everything that GRUB (when used as intended) does, which could then start my normal code that does everything as needed by the OS. It would be a complete waste of my time but it could be done. It'd be much better to use GRUB (or LILO or boot magic any other boot manager) as a chain loader and save all the hassle.

df wrote: thats essentially what freebsd does

For FreeBSD it's recommended to use FreeBSD's loader instead (GRUB won't handle it's kernel parameters)

that extra step is FreeBSD's BTX forth bootloader. Grub for some reason skips trying to load BTX and tries to load the freebsd kernel, when it should just load BTX.

It's definately not "essentially what freebsd does". FreeBSD was never designed for (or modified for) GRUB's multi-boot specification (FreeSBD has it's own boot loader "booteasy"). Instead GRUB has been specially hacked to make it look useful. Because this "special hack" isn't kept up to date with FreeBSD's kernel parameters it's recommended that you skip half of it by using more of FreeBSD's normal boot code instead.

Anyway, FreeBSD isn't limited by GRUB because FreeBSD does not use GRUB. As mentioned in an earlier post "GNU/Hurd is the only OS I know of that actually does use GRUB as intended".


Cheers,

Brendan

Solar wrote:As for bubach's list of examples...

Solar wrote: If information is readily available elsewhere, we link it, probably with a short introduction / overview of some kind. If we can write up something better, and maintain it, we write it up ourselves.

Solar wrote: Two major arguments fielded against GRUB can be identified: It makes writing a kernel too easy, and it limits your artistic freedom.

The first is, excuse me, BS in my not so humble opinion. How can you possibly complain about anything making life easier? Next thing you'll complain that beginners should write a C compiler first so they understand the peculiarities of the language...

Solar wrote: As for bubach's list of examples... aside from being incorrect and fuzzy around the edges (list of possible kernels, boot options and adding another file system are standard features of GRUB AFAIK), stuff like NUMA is pretty much advanced. I seriously doubt that people working on such advanced stuff will be looking to the OS FAQ for basic information on how to write a bootloader...

Solar wrote: If you are hanging around at Mega-Tokyo, your OS isn't yet mature enough to own a whole desktop. You are a system citizen living alongside Windows or Linux. People will be using a boot menu. Instead of forcing your boot loader/menu down their throat, you should rather have your "very special bootsector (tm)" chainloaded by whatever bootmenu the user chose to install.

I agree that we should have some words on how to write a boot sector, in addition to how to install GRUB. Writing your own MBR, however, is out of scope IMHO.

Brendan wrote:
That's sensible - a link to GRUB and a link to something like this (for e.g.):
http://www.nondot.org/sabre/os/articles/TheBootProcess/

You'd be surprised how many good programmers have never had anything to do with assembly or segmentation (and possibly less surprised how many people without any programming experience decide to write an OS).

Every training program ever created starts with easy stuff and builds up to harder things...

I didn't say "list of possible kernels", but rather "can't automatically select the right kernel to boot from a list of possible kernels", for example my OS detects the number of CPUs (and CPU features), detects NUMA presence, decides if 64 bit or 32 bit should be used (and if 32 bit decides if PAE should also be used), and then automatically selects the appropriate stage 2, stage 3 and kernel code without any user intervention. This makes it foolproof (you can't try to boot a 64 bit kernel on an 80486), more user-friendly, and in the end (IMHO) makes it a more marketable product.

As for "boot options", something to allow the user to select and test a video mode (text or graphical) before booting the OS is (IMHO) important, especially as it may take a long time before a video driver for every video card is written.

Out of the serious OS developers some won't use GRUB and others will eventually be effected by some of the limitations I mentioned.

Because of this I think serious OS developers will probably end up writing their own boot code sooner or later, so they might aswell make it sooner so they avoid the additional work of modifying a half complete OS.

All I'm suggesting is that GRUB & multiboot compliance shouldn't be automatically advocated, but instead people should be offered enough information to decide for themselves.

Solar wrote: I don't consider toying with your MBR and the A20 gate "easy stuff".

Solar wrote: And you really think people beginning to work on ther OS will think about multiprocessing, NUMA and video modes?

Solar wrote: GRUB is a very solid starting platform, and chances are slim you ever have to replace it. If writing your own bootloader takes your fancy, well, do it, but I still don't see how GRUB could "limit" you.