Hehe at the linuxbios site, "Written in C, contains virtually no assembly code" is listed as a benefit.  ;)
Posted on 2007-01-21 18:47:11 by roticv

Hehe at the linuxbios site, "Written in C, contains virtually no assembly code" is listed as a benefit.  ;)

I can see why that's a plus for the linux kernel et cetera, but just how much of a BIOS is going to be portable across architectures?
Posted on 2007-01-21 18:52:17 by f0dder
Lots of people/groups/projects don't think why they do things, they just do them because they're stuck in the mindset of "it's the right way to do things and anyone who thinks otherwise is stupid". 

One major example of this is the misconception that open source makes everything perfect.  It's amazing how many people seem to think that Java becoming open source means that it will instantly (magically) become more secure.  The ironic problem is that now people don't have to disassemble and reverse-engineer it to find the security flaws, so although it won't technically be any less secure, it'll be a whole lot easier to attack.

Another one is that no implementation should be done until everything is designed and that no testing should be done until everything is implemented, and lastly, that testing is the last phase of the development cycle.  Hmmm.... what if there's a design problem that is dependent on the implementation, and then isn't discovered until the test phase because nothing was tested before then?  Well, testing is the last phase, so the design flaw will just have to stay there throughout the lifetime of the product, because doing all testing last is "the right way to do things". ;)  If you're not prototyping your designs and trying them out during the "design phase", it's a sure one-way ticket to pain.

Perhaps the most general and problematic one these days is the "my boss told me to do it this way, so I'm doing it this way no matter what".  If you know of a better way to do something, or if you forsee a fatal problem, your boss wants to hear it.  They often get paid based on the project's productivity, so if you can save a week of work by making a simple change, let them know.  They'll often just tell you how to do something so that you won't sit there wondering how to do it.  An example of this was that a friend of mine was asked to manually remove duplicates from a huge list of names.  He wrote a simple program to do in a few seconds what would have taken him a few days. :)  His boss simply hadn't thought of writing a program for it.
Posted on 2007-01-21 19:47:51 by hackulous

Lots of people/groups/projects don't think why they do things, they just do them because they're stuck in the mindset of "it's the right way to do things and anyone who thinks otherwise is stupid". 


Agreed. Specifically for Linux/LinuxBIOS... they are too damned concerned about making *every single system* run their kernel instead of specialized kernel development that hosts a generic OS layer.


One major example of this is the misconception that open source makes everything perfect.  It's amazing how many people seem to think that Java becoming open source means that it will instantly (magically) become more secure.  The ironic problem is that now people don't have to disassemble and reverse-engineer it to find the security flaws, so although it won't technically be any less secure, it'll be a whole lot easier to attack.


Open-source has the attribute that holes tend to get closed as fast as they are opened. This only accelerates the on-going battle between malicious types and software developers.


Another one is that no implementation should be done until everything is designed and that no testing should be done until everything is implemented, and lastly, that testing is the last phase of the development cycle.  Hmmm.... what if there's a design problem that is dependent on the implementation, and then isn't discovered until the test phase because nothing was tested before then?  Well, testing is the last phase, so the design flaw will just have to stay there throughout the lifetime of the product, because doing all testing last is "the right way to do things". ;)  If you're not prototyping your designs and trying them out during the "design phase", it's a sure one-way ticket to pain.


I am overly fanatic about testing code. For my OS Development, I don't get away with more than a few blocks/procedures of code without throughly testing that it works. This is where Bochs comes in handy. After I get done implementing entire ideas/designs, I test on a real PC and work things out from there.


Perhaps the most general and problematic one these days is the "my boss told me to do it this way, so I'm doing it this way no matter what".  If you know of a better way to do something, or if you forsee a fatal problem, your boss wants to hear it.  They often get paid based on the project's productivity, so if you can save a week of work by making a simple change, let them know.  They'll often just tell you how to do something so that you won't sit there wondering how to do it.  An example of this was that a friend of mine was asked to manually remove duplicates from a huge list of names.  He wrote a simple program to do in a few seconds what would have taken him a few days. :)  His boss simply hadn't thought of writing a program for it.


It's easy... just make the boss think it was their idea :P
Posted on 2007-01-21 20:45:25 by SpooK

no testing should be done until everything is implemented

I don't agree with this one - it's beneficial to test at least each "module" when you can, and (while I've not gotten into this myself yet) for things where it's possible, it seems like a pretty decent idea to have an automated regression suite to test with, and do that relatively often (though not after each compile, as some people advocate).

There's a reason why filesystems are often implemented in ring3 before integrated to kernelmode ;)
Posted on 2007-01-22 04:38:12 by f0dder


no testing should be done until everything is implemented

I don't agree with this one.

Sorry, that was my point (i.e. that testing shouldn't be left until the end).  I guess it's hard to identify sarcasm in text-only.  ;)
Posted on 2007-01-22 10:49:56 by hackulous



no testing should be done until everything is implemented

I don't agree with this one.

Sorry, that was my point (i.e. that testing shouldn't be left until the end).  I guess it's hard to identify sarcasm in text-only.  ;)


That's why we usually use smilies, no? ^_^
Posted on 2007-01-22 17:12:16 by f0dder
Alright, since we are still on this subject I thought maybe I could ask another question! When I am copying my Global Descriptor Table at the physical address of 0x0500 after the BDA and then switch to Protected Mode with the Flat Memory Model, would I be overwriting my GDT if my code or data grows in the memory? Do I even have to be worried about that or would it stay in GDTR?

P.S: Wouldn?t it be a good idea to let me ask all of my questions in this post and then make this post sticky or put it in the FAQ section? Seriously because I know there are other people who have the same questions but can?t possibly be as annoying as I am!

Posted on 2007-01-24 00:26:38 by XCHG
We're in the process of rewriting the FAQ and wikifying the current content in there, so the FAQ can actually become a FAQ :). But some of the stuff from this thread could go into wiki entries, sure!

Personaly I don't copy the GDT, I use a temp one for initial loading, then set up a new GDT when in pmode.
Posted on 2007-01-24 00:40:15 by f0dder
You'd only be overwriting your GDT if you chose to write to memory in a location occupied by your GDT.  I've got my GDT at physical and virtual address 0, specifically because I want to generate an error on trying to "dereference a null pointer" anyway (an access violation, because I have that page at supervisor access level).

One weird and possibly counter-intuitive thing is that the address in the GDTR is a virtual address, (or maybe I'm confusing it with something else).  To avoid the confusion, I have the physical address of it and virtual address of it equal.  ;)
Posted on 2007-01-24 01:10:19 by hackulous
All addresses except Page Directory (including CR3/PDBR) and Page Table entries are considered "Virtual Addresses" while the Paging-bit in CR0 is enabled. This makes more sense as you get deeper and deeper into virtual memory and multitasking.

The best explanation I can provide comes from my init routine.

The GDT/GDTR are data structures included in the kernel, they are not copied to any location. Instead, the relocation address fix-ups take care of the GDT/GDTR addresses due to their inclusion in the kernel file format (e.g. PE/ELF/etc...)

Please note that in 16-bit Real Mode, only 24-bits of the 32-bit GDT address within the GDTR are utilized. This allows me to easily use "LGDT" only once and never look back. How I utilize paging within 32-bit Protected Mode also reflects/supports this method.

This is a rather incomplete explanation of what is really coded, but I hope you generally understand what I mean.

I will probably release my init code, which is in (N)ASM, sometime within the next week for people to use and learn from.
Posted on 2007-01-24 01:49:17 by SpooK
I wouldn't place my GDT at phys0 - if you want to do v86 later on, it's nice having the original IDT to copy from.
Posted on 2007-01-24 03:44:20 by f0dder

I wouldn't place my GDT at phys0 - if you want to do v86 later on, it's nice having the original IDT to copy from.

Good point.  I don't plan on doing any v86 later on, but I should save the int 10h vector, because I'd like to emulate the changing of screen modes eventually.  I've also got conditional assembly in my code so that if I change the GDT's physical or virtual address from 0, it'll automatically adjust.  (It's also really handy for forcing errors when a constant changes or a structure's size changes, so that I can update anything dependent on it.)
Posted on 2007-01-24 11:25:42 by hackulous
Just saving a single vector might not be enough - what if the interrupt code decides on calling interrupts itself? - the realmode ivt is 1kb, right? Not a big loss of memory :)
Posted on 2007-01-24 12:02:26 by f0dder
This is great, thank you guys for being so helpful and tolerant. I appreciate it.
Posted on 2007-01-25 02:01:52 by XCHG
Can you guys give an advise on whether I?ve gotten this whole memory layout right by telling me whether or not my definitions for the below terms are correct?

Physical memory: is the actual RAM addressable directly when paging is not enabled.

Global Descriptor Table: is a table created in the memory which holds the base addresses, segment limits and access rights of different segments in the memory.

Logical Address: is the far pointer created by adding a segment selector inside the GDT and a 32-bit offset which would then be translated into the linear address.

Linear address: depending whether paging is enabled or not, in the former case would be mapped into the physical memory through the paging directory and tables and in the latter would be mapped directly to the physical memory.


I don?t know whether these descriptions are correct or not but there is one thing I barely understand about the linear address. The Intel manuals state that the linear address is made of *adding* the segment selector and the offset of a byte. So suppose my code segment descriptor in the GDT has the offset of 8 (right after the null-descriptor) and I would like to address the 10th byte inside this segment. Would the linear address of this byte be equal to 0x08 + 0x0A = 0x00000012?
Posted on 2007-01-26 03:49:42 by XCHG
No, you don't add the selector - you add the base-address from the L/GDT descriptor entry the selector selects :)

Oversimplified code that doesn't take LDT/GDT into account etc:
linear = logical + gdtArray.base

Posted on 2007-01-26 03:55:22 by f0dder
So if a sgment has its base address set to 0, then any operation using this segment has its logical address equal to linear. That's exactly the essence of the 'Flat Memory Model'. In other words: The segmentation is being 'disabled' this way (of course there are some exceptions).
Posted on 2007-01-26 08:43:21 by ti_mo_n
:shock:  I remember reading the stuff about linear vs. logical and never actually needing it.

I just keep it simple, having the base segment addresses at 0 (except on TSSs of course), and then I can call everything virtual or physical.  A virtual address is one that you can actually use as a normal address after booting (i.e. with paging enabled), and a physical address only matters to the page-level memory functions and possibly device management functions later.  I think that they're trying to or have already phased out segmentation with the 64-bit mode (though I don't have such a processor, so I haven't looked into it much), so it's best not to rely on segmentation much anyway.  ;)
Posted on 2007-01-27 00:55:27 by hackulous
Okay got it. Thank you everyone. Although it?s really sad to hear that they are going to get rid of segmentation (are they?) just when I am starting to learn it. It?d be so sad.
Posted on 2007-01-27 01:17:27 by XCHG