OSDev.org

Well I need to add my idea for the configuration script of my boot loader which is still in design. I wanted to use something that already exists, is easy to learn and something easy to expand so I decided to use some form of BASIC as the scripting langauge. The complete boot loader with interpreter and some useful libraries like vga/vesa control, file support and a simple boot menu system should be small enough to fit within 64K. A script file called boot.scr (file name not chosen yet) similar to the grub2's 00_header would be loaded first to set some defaults and include any common libraries with the internals something like:
Which includes bootlist.scr, your custom boot menu list which sets all the settings like the screen resolution and the background image. The default screen mode would be text 80x25 and the default time out, file system and root from boot.scr could be overwritten.
The menuitems could be in separate files and included into bootlist.scr. This is still in design mode and probably overly simplified but seems workable. Some things still need to be worked on like it would be case sensitive and all internal variables ($ROOT, $TIMEOUT) would be in upper case while user defined could be lower case or camel case.

Hm I never thought of using a scripting language in the boot loader.. Have you gotten anywhere with that?

havok wrote:Hm I never thought of using a scripting language in the boot loader.. Have you gotten anywhere with that?

I have the boot sector and a simple boot loader but not the interpreter yet. There are a few examples of small BASIC interpreters I've thought of basing it on.

Eventually it will support multiboot v1 and something similar to the BTX boot loader for freeBSD with a BIOS pmode interface. This is the part I'm currently working on.

Hi,

I've been doing something like this for a while now.

The boot loader loads a plain text file (in addition to some other files, including a "boot image"), where each line in this file is either empty (whitespace), contain a comment, or contains a "<variable> <value>" line. Mostly it's used like environment variables.

To make parsing easier, the first character of a variable name determines the variable's type - "!foo" is a boolean, "$foo" is a string, "*foo" is a file name, "%foo" is an integer. File name variables refer to files in the "boot image" (that is also loaded into RAM by the boot loader), and file name variables are treated as errors if the file name doesn't exist in the boot image. An example might look like this:
The text file is parsed once during boot, and the boot code maintains a list of variables and their values after that. Any boot modules can read variables, change variables and create new variables; and the boot code keeps track of which variables have been accessed and/or modified. After boot, (if something changed) the OS can generate a new file from the variables to replace the old file, so that variable values are persistent. Variables that aren't accessed by anything are discarded (to keep the file tidy).

I've never needed anything more complex than this for my OS, and for my purposes something like a complete scripting language would be overkill and create unnecessary problems. For e.g. it would be difficult for the OS to auto-generate the script and difficult for the boot code to include a simple menu-driven interface for different settings; and end-users would have to learn the file's syntax and edit it manually (from a "user-friendliness" perspective that just smells like a design failure to me).


Cheers,

Brendan

Brendan wrote: I've never needed anything more complex than this for my OS, and for my purposes something like a complete scripting language would be overkill and create unnecessary problems. For e.g. it would be difficult for the OS to auto-generate the script and difficult for the boot code to include a simple menu-driven interface for different settings; and end-users would have to learn the file's syntax and edit it manually (from a "user-friendliness" perspective that just smells like a design failure to me).

Yeah this makes sense if you are automatically generating the scripts but with a proper scripting language a user can quite easily modify the boot loader script. Also only including enough support for your own OS in the boot loader is limiting the users options for booting multiple OSes.

I think with a common language like BASIC it's almost second nature to know what is happening to a user but with a custom script a user may need to look up how a command works.

Brendan wrote: To make parsing easier, the first character of a variable name determines the variable's type - "!foo" is a boolean, "$foo" is a string, "*foo" is a file name, "%foo" is an integer. File name variables refer to files in the "boot image" (that is also loaded into RAM by the boot loader), and file name variables are treated as errors if the file name doesn't exist in the boot image.

I did see this used in some small BASIC languages but I didn't like that fact that I had to type cast the variable I was using.

Been a bit since my last post.. Have been doing some reworking of my boot loader. Anywho for those who are interested i have finally decided how I will do Boot Loader Configuration.

Basicly it will be a binary file.. Yup I know almost defeats the whole purpose of using configuration files except that it completes my goal of being able to configure bootloader options without having to either recompile the Boot Loader or Kernel. The normal user won't have to mess with the configuration file itself ..at least on my operating system as it will provide an interface to change options in a 'safe' manor. How ever since it is an extremly easy spec it should be no problem for programmers to either support or use.

It follows the multiboot spec almost completly as far as what information is offered to the kernel. However it differs in that it supports setting up pageing (the spec supports setting the pageing mode but as of right now my bootloader only supports 32 bit pageing). it also supports entering P-Mode. However it has seperate options for P-Mode and Setting the Descriptor table. (either kernel sized only or full 4 gig access). the smart bootloader could use the seperate bits to enable unreal mode. In addition users are able to tell the bootloader what file sections it wants loaded. and (more for the benifit of my kernel) the ability to specify what drivers to load from disk and what drivers to link to internel driver base.

My boot Loader tries to load the configuration file and if it cant find the configuration file it falls back on using the multi boot spec. In this way it retains backward compatability.

If anyone is interested in this spec it has a basic definiton in progress on my project home page http://embos.wikispot.org/Tables .
Please bear in mind that this is still being developed and if you have questions you can check back on a day or so (when i plan to have the spec rouph draft completed) or ask them on here.

Sounds good. Why I think Grub doesnt support setting up paging is probably because the kernel will most likely overwrite it with it's own. However for an entry start operating system it might be a good idea.

How will the configuration of modules work?

Wow that was a quick response lol.

Basicly my operating system is developed with a highly moduluar approach. Every thing except the kernel (which ties all the modules together) is a module. including the task manager, memory manager, etc. The system administrator has the ability to configure which modules are used and (my goal) and even have them swapped out while the system is running. It took me 2 weeks to design a system that would easily support this feature as it would involve re-linking code etc. So what i decided is the kernel has built in basic modules that support basic functionailty. the iport section of the kernel lists dummy module names that match up to sections in another configuration file (that will remain in ram during system loading initalization (at least for the intended use)) that configuration file will list what modules link to which type.. ie:
in the case of that config file the linker would parse the iport section of the kernel and see a match for a function in Video.mod instead of loading Video.mod it would check the configuration file and see Video is set to VideoModule.mod and load that instead. any un-listed entry would automaticly be linked to the internal module built in to the kernel......

make sense? sorry its late and my brain is only half working. lol

as far as how the bootloader handles this. i expect that it will check the 'Module Specifics Exist ' bit and if set would search the filesystem for the configuration file mentioned above.

Edit: Just completed the rouph draft of the Boot loader configuration file. i used nasm data notation. for those who dont use nasm, db is a byte. dw is a word. dd is a double word. Let me know what anyone who is interested thinks.

I've designed a system that does not rely on the OS configuration being present on a harddisc, and thus I support running RDOS without any type of persistent storage. The class library for RDOS has a library for creating OS images. This library can be linked to an application to allow building dynamic OS images (this is used in our payment terminal). There is also a standard tool that uses this library to convert a configuration file into a OS image. This standard tool is portable and currently runs on Win32 and RDOS, but can easily be ported to other OSes as well as it contains standard-C code.

The configuration tool handle the following types of information:
* Which kernel to use
* Which panic-device to use
* Which device-drivers to use (and which parameters that are passed to them)
* Which files are preloaded to drive z: (ramdrive)
* Which programs that are autostarted at boot-time
* Path setting
* Environment settings

All the above things are written into a single OS image file. This image file can then be loaded into memory by GRUB, and can run stand-alone even if RDOS cannot access the filesystem on a particular machine. The OS image can also be burnt into a flash-chip, and loaded with a custom boot-loader, or mapped directly to physical memory as a read-only device.

Dynamic settings (like IP address) are handled with environment variables, which are coded into the OS image.

Because if you never re-invent the wheel, you'll never get a better wheel?

It's probably not economically viable to write this bootloader (the opportunity costs of this are being able to write other more useful pieces of code) but if nobody ever wrote software that's not economically viable, this forum would be much like a ghost town.

Personally I use the bootloader written by AlexExtreme, which is flexible and has a configuration mechanism.

Never needed anything else, I ditched grub a while back.

berkus wrote:All wheels invented so far have been fairly round.

Having a better wheel is achieved by improving on the current designs, not starting all over again.

Im not reinventing the wheel...just adding a few extra lugnuts..(more options for loading the kernel)

havok wrote:

berkus wrote:All wheels invented so far have been fairly round.

Having a better wheel is achieved by improving on the current designs, not starting all over again.

Im not reinventing the wheel...just adding a few extra lugnuts..(more options for loading the kernel)

If you design support for loading an OS that is not a binary 32-bit image (like GRUB requires) directly, I'd be interested.

rdos wrote:

havok wrote:

berkus wrote:All wheels invented so far have been fairly round.

Having a better wheel is achieved by improving on the current designs, not starting all over again.

Im not reinventing the wheel...just adding a few extra lugnuts..(more options for loading the kernel)

If you design support for loading an OS that is not a binary 32-bit image (like GRUB requires) directly, I'd be interested.

since it allows you to specify the sections loaded and what version of pageing if any and what form of pmode if any i dont see a problem. but specificly what are you looking for? maybe if the spec dosnt support it we can work it in. Thats what im working on here trying to get a feel for what people want in a spec so we can make everyone happy.

havok wrote:since it allows you to specify the sections loaded and what version of pageing if any and what form of pmode if any i dont see a problem. but specificly what are you looking for? maybe if the spec dosnt support it we can work it in. Thats what im working on here trying to get a feel for what people want in a spec so we can make everyone happy.

It is probably more or less impossible to add RDOS loading support directly into any kind of general-purpose bootloader. This is due to the use of custom headers and CRCs. However, I could define a new header which would could list some characteristics of the image that a bootloader needs to know about. Specfically this:

* The byte offset of the kernel in the image
* The size of the kernel in the image
* The start IP in the kernel image

With this header, the bootloader could create a new 16-bit code-selector, and jump to the entry-point, which is basically all that is required. It also should pass some basic configuration (most importantly, where the image is located, where usable physical memory is available) to the entry-point.

Which selector to use for the image could be a configuration option, as well as it's bitness (16 or 32-bit) and memory model (segmented, flat). The size, position and entry-point cannot be configuration options as they will vary per build. I think you need some type of structure in the loaded images, similar to the multiboot header, just with more options.

As for starting paging, I cannot see how this could be done in an OS-independent way.