Boot Configuration Structure

Discussions on more advanced topics such as monolithic vs micro-kernels, transactional memory models, and paging vs segmentation should go here. Use this forum to expand and improve the wiki!
Post Reply
User avatar
b.zaar
Member
Member
Posts: 294
Joined: Wed May 21, 2008 4:33 am
Location: Mars MTC +6:00
Contact:

Boot Configuration Structure

Post by b.zaar »

Hi, I've created a System Configuration table to be used by my boot loader and kernel. It's a simple design but I'd like some opinions on it.

The html document can be downloaded here. It works on a block system and is easily extended by creating new blocks in the specs. Any private data can be stored in the table inside a reserved block. I plan to use this alongside the Multiboot 1 structure as some of it overlaps but it also supplies more information than Multiboot 1. It can be passed to the kernel using the ESI register as a pointer and the magic number is stored inside the table.

Any suggestions for other block types would be helpful too.
"God! Not Unix" - Richard Stallman

Website: venom Dev
OS project: venom OS
Hexadecimal Editor: hexed
User avatar
bluemoon
Member
Member
Posts: 1761
Joined: Wed Dec 01, 2010 3:41 am
Location: Hong Kong

Re: Boot Configuration Structure

Post by bluemoon »

b.zaar wrote:Any private data can be stored in the table inside a reserved block.
As for any specification, you want to provide flexibility but it usually get messy as everyone (if there is any) just implement their own extension and defect the idea of standard interface.

I would suggest to remove such private, or undefined zone, and have enough research so that you got every needed information on the interface at the very beginning.
User avatar
b.zaar
Member
Member
Posts: 294
Joined: Wed May 21, 2008 4:33 am
Location: Mars MTC +6:00
Contact:

Re: Boot Configuration Structure

Post by b.zaar »

bluemoon wrote:
b.zaar wrote:Any private data can be stored in the table inside a reserved block.
As for any specification, you want to provide flexibility but it usually get messy as everyone (if there is any) just implement their own extension and defect the idea of standard interface.

I would suggest to remove such private, or undefined zone, and have enough research so that you got every needed information on the interface at the very beginning.
A few reasons for the reserved block:

1. It is difficult to remove a block if it can not be completed for some reason. The reserved block ID is used to free/reserve this block as bad data.
2. I could not possibly foresee every desired/necessary block type. If this spec becomes used by others someone somewhere will create a reason to define their own data block. This could be for a custom piece of hardware they have designed for a PC or for a specialised data block that is used on a microcontroller system. It can also bo used to test a new data block type before it is added to the official spec.
3. The PNG file format (one inspiration for the SCFG design) uses a private data chunk.
"God! Not Unix" - Richard Stallman

Website: venom Dev
OS project: venom OS
Hexadecimal Editor: hexed
User avatar
b.zaar
Member
Member
Posts: 294
Joined: Wed May 21, 2008 4:33 am
Location: Mars MTC +6:00
Contact:

Re: Boot Configuration Structure

Post by b.zaar »

A small update to the SCFG specs, a new private data block has been created. The new block will allow private data to be included with less chance of the data being identified incorrectly.

The specification is now also available for reading online.
SCFG Private data block.
"God! Not Unix" - Richard Stallman

Website: venom Dev
OS project: venom OS
Hexadecimal Editor: hexed
Post Reply