OSDev.org

Hi, I'm new here but I've talked to a few people here before and I'm active over at the alt.os.development newsgroup.

As a bit of background I started work on my own OS 2 years ago after looking for a project to join but finding them all too complex for the level I was at. Looking back at this experience I realised that what we are missing most is a good repository of OS 'components' which can be dropped into an OS project with minimal modification.

The only projects I have found covering this area are the Flux OSKit and libOSDK. Neither is really what I want, the OSKit is a monolithic library where including one part requires the rest and libOSDK is a library in assembly language. The OSKit is also very static having not released any code for a couple of years now. The key features I am looking for are:

1) Components must be separate so including one requires few dependencies, and those dependencies are clearly listed.

2) Multiple components can do the same job so a developer could choose between a component which follows a traditional approach and one which demonstrates a new way of doing things.

3) Components should be able to follow their own release timescales.

With the right people involved, this could become a showcase of new OS ideas since only a single component would need to be written rather than a full OS just to demonstrate 1 feature. With a good set of guidelines and standards, all the components can have a similar look and feel and one component can be swapped for another which does the same job with minimal change to the target OS.

A set of guidelines and standards will be developed to tie all the components together and help compatability between components. Standard interfaces will be used where more than one component fits into a category (eg. filesystems), and will be used as needed in other areas.

The guidelines will only be what is needed to help portability across compilers, the format of function names (proc_create or CreateProcess), the idea that components should only export functions (not variables) and lastly some rules to avoid collisions between identifiers in different components.

Guidelines and standards should be minimal. The idea is maximum freedom within the limits that are needed to give a consistancy to the project. The less points of argument there are, the more developers will be interested.

The nice thing with this idea is that it can be taken in several directions. Sadly, that means I need to decide my direction before writing anything. One other option I'm seriously considering is just writing a kernel, made up of many components, where each interface is standardised and people can write their own replacement components easily. This does away with the requirement for components to be easily dropped into any kernel, but still allows many components implementing the same job. Let me know if this sounds like a better direction.

I have a website that can be used as the projects base, and some of my OS code can be quickly stripped of dependencies and posted to get this thing kick started (a library of x86 assembly language functions and a self-contained physical memory manager are the first things I can think of). I also have the time to be the maintainer and co-ordinator of this project.

So, the real question here is what do you think? Is it a good idea? Has something like it been done and if so, where? I've not been too specific here since all the details are up for discussion once I know this project has some supporters.

Thanks in advance,
Paul Barker

I was thinking about doing a similar project, some years a go http://board.flatassembler.net/topic.php?t=2020
I was call "ASHLEY4" then.
But if you want a example of port able code, then you can do no better than take a look at fasm source, it only take me about 2 hour to get it working on my OS.
This is done by keeping OS dependent code to the miniman and in a separate inc file and well documenting the interface, i know it not a part of a OS as such, but still a good example.

hi paul!

nice to get news from you

btw, there's the "OSLib" project .. pretty low level stuff iirc, but they have easy to import components (at least, importing their vm86/vbe stuff didn't took too long).

For the rest, it may be more complex and i don't really see how one could e.g. provide a "component" for mutithreading or ultradma disks, for it requires _many_ stuff and may assume miscellaneous functionalities from the hosting OS.

Cheers, I'll take a look at oslib tomorrow (I'm assuming you mean the one at oslib.sourceforge.net).

I'm thinking of starting with really simple things that are pretty much self-contained. For example, my physical memory manager only used spinlock and list functions which can easily be adapted to a new OS.

As far as multithreading goes, I can see an easy way of providing a scheduler that can easily be dropped into any OS, with the OS only providing a switch_thread() method, thread priorities and calling the scheduler when needed (the scheduler would be round-robin within priority levels).

Devices will be left to later, but I have seen a couple of attempts to make a standardised device interface and I could get this project to work with one of those standards.

And for the misc. functions, I was thinking of splitting the project into a core library which all components can rely on (absolutely minimal) and the components on top of this. It's all open to discussion and suggestions of course.

I'll post some more details tomorrow (when I've looked at oslib) because there are several directions I can go with this sort of idea.

OSlib is rather simple, and uses GPL'd code. It also has stuff under the BSD license. If your license conflicts, GPL wins . I don't really recommend using OSlib

Cheers, DH.

I think the basic libc code there could be very useful, and there does look to be some nice little bits floating around (FPU support, BIOS calls, VM86). As far as my project goes I'm really trying to work out how to get the components as independent as possible.

I just wanted to elaborate on the 3 directions I could take this idea.

1) Build a microkernel where all components on top of this (drivers, filesystems, etc.) are developed in the way I've explained. This way there is a standard interface that can be used by all components, and people can just write little components as they choose. The disadvantage here is that if someone wants to re-write a core kernel part it won't be as easy.

2) Build a kernel (probably micro) where each component has a well-specified interface, so that multiple components can be written to do the same thing (the traditional vs. new argument in my first post). This way if someone wants to write just one part of an OS it is easy, and the end-user has many choices he can make about which components are usable in the kernel. This would target mainly hackers and os-devers since the customizability is the main aim. This means each component does not have to be independent and can rely on other components being present (thru a standard interface so the implementation does not matter).

3) Follow the original idea that components should be written so they can be dropped into any OS.

(3) is only viable if I can get some people interested and get the issues worked out. (1) or (2) would also need to attract some developers, and I think approach (2) would make my kernel stand out and give it something unique. All 3 approaches are likely to produce a research OS rather than a general-purpose OS, so the target will be hackers and os-devers whatever direction I go in.

Any ideas, advice and flaming other feedback would be welcomed,
Paul Barker

My idea for an oskit type thingy would be provide a libc for kernel use, and add some stuff to it for a kernel such as say multithreading or dma
and yea then say for getc()(from keyboard) there be a keyboard buffer in the lib and when an irq1 happens it be required that you use a function that puts the pressed key in the buffer and then getc just gets what is on the buffer or if the counter=0 then wait until counter is 1