OSDev.org

First I would like to say hello to everyone. This is my first post to this forum but I have been reading the forums for a few weeks now. I have been working on my operating system for only a short time (only a couple months) but have decided to do a overhaul of the bootloader because I don't like the way I implemented a couple of the features.. Anyways came up with a new idea that as far as I know hasn't been done before and I thought it would be great to get the opinion of some of the people on here. So here is my idea:

Have the bootloader first load a configuration script using xml that tells the bootloader what the kernel wants to be done. The major advantages of this in my mind are:
1. Ease of configuration using human readable language instead of bit toggling.
2. Can change what you want the bootloader to do without having to recompile any of the code.
3. Easy to add new features in the future just by defining new tags. (If implemented correctly new tags should not break existing code.)

I have not researched this idea very far past basic implementation so if this has been thought of before I apologize and don't mean to try to take credit.

Anyways thank you for the resources and the help that everyone here gives. I can say with out a doubt this is the first website I turn to when having any questions with my project.

edit-I wrote a basic function that can find any tag in an xml document as long as the case matches (which might be preferable?).
It is 46 lines of assembly code including local variables, machine state save and restore code and labels. It takes a pointer to a tag and a tag lenth and returns a pointer to the start of the data (directly after the '>') and the size of the area between the '>' and '<' including white space.

Hi,

I'm not exactly sure what berkus meant, but your idea seems plausible. The only problems that I can think of are that users can easily mess up the xml file, and therefore, the system and that malicious software could also mess up the xml file, once again messing up the system. But of course, these problems are nowhere near practical. Other than that, your idea seems fine to me. Although, keep in mind that you may need to use a two stage bootloader, should your code exceed the limit of a single stage bootloader.

And as I said before, I'm not sure what berkus meant with the above post, but I know that he is a respected member at these forums, so i'm sure he has a good point to make, although to me, his post seemed somewhat derogatory.

-U238

It seems kind of pointless. Most of the bootloader configuration is a one-time thing, so it makes sense to write it into the binary itself. Anything else is so simple that XML is overkill. The bootloader configuration script could be something as simple as a .INI file. Think about how you tell GRUB which OS's to boot. It is basically just a shell script using commands only recognized by GRUB.

Hi,

Tosi has made an excellent point, although, havok seems to intend for his bootloader to handle configuration settings and loading modules(see quote below), which can vary as the user can (presumably) change various settings and as new modules are added. Having all settings and modules hardcoded into the bootloader limits flexibility, especially since the bootloader would have to be recompiled every time a new module is to be added.

havok wrote:The major advantages of this in my mind are:
1. Ease of configuration using human readable language instead of bit toggling.
2. Can change what you want the bootloader to do without having to recompile any of the code.
3. Easy to add new features in the future just by defining new tags. (If implemented correctly new tags should not break existing code.)

Note that when I wrote "modules", I was referring to the "new features" that havok wrote. I just assumed that, since the way he described them seemed like he was talking about a modular system where features could be added or removed. Nevertheless, the same basic principle still applies.

-U238

U238 wrote:Hi,

Tosi has made an excellent point, although, havok seems to intend for his bootloader to handle configuration settings and loading modules(see quote below), which can vary as the user can (presumably) change various settings and as new modules are added. Having all settings and modules hardcoded into the bootloader limits flexibility, especially since the bootloader would have to be recompiled every time a new module is to be added.

Thanks U238 that's exactly what I intend. This idea might be applicable to only a couple operating systems though.

U238 wrote:
Note that when I wrote "modules", I was referring to the "new features" that havok wrote. I just assumed that, since the way he described them seemed like he was talking about a modular system where features could be added or removed. Nevertheless, the same basic principle still applies.

-U238

Again right on the money. EmbOS is designed to extremly modular. Also settings wouldn't be limited to OS Loading options. Other things about the bootloader could be specified also. (BootLoader splash screen, Setting verbose mode, just a couple examples). After all how many people devoted countless hours to changing the windows 95/98 splash screen?

U238 wrote: The only problems that I can think of are that users can easily mess up the xml file, and therefore, the system and that malicious software could also mess up the xml file, once again messing up the system.

A very good point. I have thought about this before during my feature design phase and came up with the idea that at boot time (and any other time a module gets loaded) it gets checked through signiture checks and checksum checks. If it fails these tests it gets outright rejected. The kernel is compiled with basic modules included. (Memory Manager, Task Scedular, simple vga driver, etc). In the event that the linker cant load the basic required modules then it links in the compiled in modules.

berkus wrote:

U238 wrote:Tosi has made an excellent point, although, havok seems to intend for his bootloader to handle configuration settings and loading modules(see quote below), which can vary as the user can (presumably) change various settings and as new modules are added.

But this is no excuse to overcomplicate things. XML is useless at this point, it conveys the same meaning as (example):

Code: Select all

<group1>
   <group2>
      <label name="one" type="pathname">~/project1/floppy.img</label>
      <status>inserted</status>
    </group2>
</group1>

is easier spelled as:

group1.group2.one=~/project1/floppy.img
group1.group2.status = inserted

See how much cleaner and readable that is? There are other advantages to not using XML too (and some disadvantages - such as XML files could be validated given a schema definition and a validating parser, but, honestly, would you ever do that to a one-time config file?)

U238 wrote:Having all settings and modules hardcoded into the bootloader limits flexibility, especially since the bootloader would have to be recompiled every time a new module is to be added.

This has nothing to do with the config file format, really.

hmmm Interesting point berkus. I guese that since I am planning to use xml to configure most of the operating system later on in the boot proccess that it would be a logical step to extend that functionality to the bootloader. But that is why i posted here so we can go over ideas and look at them in a different light and determine if an idea which may seem good is actually a good idea or as in this case an over complication.

So now to the original idea. Is the idea of a configuration script a good one, maybe using a language other then xml?

berkus wrote: Code:
<group1>
<group2>
<label name="one" type="pathname">~/project1/floppy.img</label>
<status>inserted</status>
</group2>
</group1>

is easier spelled as:

group1.group2.one=~/project1/floppy.img
group1.group2.status = inserted

Actually got thinking about it and on first glance it seems that parsing that type of data structure would be harder then xml.
I say this because with xml you already have known charecters in place '<,>' to use to jump around the file to find the data you want using 'scasb' where as with the format you showed you would have to scan the entire file. Currently my xml scan function checks only the tags and ignores the rest of the data till it comes to the tag thats being searched for. I would like to think that that would make the function a bit quicker. The only other thing i could think of to make scanning a file in the format you sugested quicker would be to put things in a specific order but if code counted on that order then changing the order or inserting a new property in a logical place (but not at the end) would break any code using that.

berkus wrote:

havok wrote:I would like to think that that would make the function a bit quicker. The only other thing i could think of to make scanning a file in the format you sugested quicker would be to put things in a specific order but if code counted on that order then changing the order or inserting a new property in a logical place (but not at the end) would break any code using that.

Parsing this code is dead simple, you read one line and then you insert it in a tree by grouping at the "." until the "=", the rest is leaf value.

So in essence you would have to read the entire file in a structure before using any of the data? Im not sure how this would be quicker or even more effecient for large configuration files. Maybe I am just mis understanding your idea though.

berkus wrote:

havok wrote:So in essence you would have to read the entire file in a structure before using any of the data? Im not sure how this would be quicker or even more effecient for large configuration files. Maybe I am just mis understanding your idea though.

How do you intend to read/parse the XML file then?

Of course you can do a stream (line-by-line) parser for either text or XML config file, but it's nothing better than U-boot cmdline then, just two orders of magnitude more verbose.

My parser takes 2 values as input ( ptr to tag and size of the tag and a ptr to the begining of the file) it then uses scasb to search the file for the first char in the tag (should be '<') once found it checks that tag to see if its the one its looking for. if not then it goes back to scanning till it gets to the next tag. (could be changed to ignore closing tags). once found it returns a ptr to the begining of the data (right after the '>') and the size between the 2 tags including white space. the design of this also allows you to break the file up into smaller chunks. i.e. search for <kernel parameters> then search for another tag passing the location of <kernel parameters> instead of the beginning of the file.

You wouldnt have to.

Ill give an example and psuedocode
to get the physical load address you could do to things:
1.
pass <kerneloptions> to search function with file ptr as the point to start searching at with the file lenth
then pass <kernelphysicaladdress> to search function with result of first search as a point to start searching. that would limit the search to only between the <kerneloptions> tags.
2.
Just search for the <kernelphysicaladdress> tag in the first run. This would give the same end result but ineffective for parsing a bunch of information from the same section expessially in a large file.


This would probbally only be effective though if you had at least 2 large sections. like a large section of kernel arguments and a 2nd large section of bootloader arguments (such as verbose, graphical mode, splash screen image,etc).
In that case a bootloader that dosnt care about the bootloader arguments for example could ignore that section completly.

here is a copy of the working config file i am using to write the functions

berkus wrote:
Using XML for a simple config file is not overkill, it's like shooting microbes on your face with an Ion Cannon. Your face would probably get melted in the process.

ROFLMFAO !!!

berkus wrote:

havok wrote:You wouldnt have to.
to get the physical load address you could do to things:
1.
pass <kerneloptions> to search function with file ptr as the point to start searching at with the file lenth

Lets recap again. The above means the file is already in memory in its entirety, right?

Then I don't see any advantage in searching the matching tags pair (and failing if you accidentally misspelled one) compared to just reading a short line in the buffer, looking for a match and looping again.

Instead of searching for kerneloptions and then for kernelphysicaladdress you'd just search for kernel.physicaladdress= and be done with it.

In a modular system, modules' name could server as prefix (kernel. in this case, for the root kernel module) and the rest of the line would be module specific.

And your XML file would look approximately like this:

Code: Select all

kernel:
.Name = EMBK.BIN
.PhysicalLocation = 0x10000
.VirtualLocation = 0xC0000000
.PagingEnabled = True
.ProvideMemoryMap = True
.ProvideDiskMap = True
.LoadAllSections = False
.SectionCount =
.SectionName = Text
.SectionName = rData
.SectionName = Data
.SectionName = eData
bootloader:
.DisplayMode = Text
.Verbatim = Yes

Ok that makes a bit more sense. I have to admit (maybe im just dense lol) how would you be able to search that for say .DisplayMode without having to parse the structure in full? granted right now I can't think of enouph options that would make this unfeasable but lets remember thats the same thinking that pc manufatctures used when setting the memory limit at 1MB.

hmmmm I have never heard of YML but i just did a quick google search and I think your right. At first glance it dose seem to be a bit easier to use. ill have to look into it more.

havok wrote:First I would like to say hello to everyone. This is my first post to this forum but I have been reading the forums for a few weeks now. I have been working on my operating system for only a short time (only a couple months) but have decided to do a overhaul of the bootloader because I don't like the way I implemented a couple of the features.. Anyways came up with a new idea that as far as I know hasn't been done before and I thought it would be great to get the opinion of some of the people on here. So here is my idea:

Have the bootloader first load a configuration script using xml that tells the bootloader what the kernel wants to be done. The major advantages of this in my mind are:
1. Ease of configuration using human readable language instead of bit toggling.
2. Can change what you want the bootloader to do without having to recompile any of the code.
3. Easy to add new features in the future just by defining new tags. (If implemented correctly new tags should not break existing code.)

I have not researched this idea very far past basic implementation so if this has been thought of before I apologize and don't mean to try to take credit.

Anyways thank you for the resources and the help that everyone here gives. I can say with out a doubt this is the first website I turn to when having any questions with my project.

edit-I wrote a basic function that can find any tag in an xml document as long as the case matches (which might be preferable?).
It is 46 lines of assembly code including local variables, machine state save and restore code and labels. It takes a pointer to a tag and a tag lenth and returns a pointer to the start of the data (directly after the '>') and the size of the area between the '>' and '<' including white space.

What are we suppose to discuss here? I don't see any question. You describe a proposal where you want to configure your boot loader using a XML-script. Sure, if it works for you, why not. I don't see any real problems with this. If you like XML, that's your choice.

havok wrote:... and I thought it would be great to get the opinion of some of the people on here.

He asked for our opinions.