OSDev.org

Hey everyone, I'd like to announce the third release of my kernel! It has been a long six months of development, and now I have finally reached the 'stop' point, so to speak.

From the user's perspective, not much is going on with this kernel. I've added support for virtual consoles, which seem to work rather well. Most of the action is going on under the hood, however.

I've converted most of the code to C++, and I make rather heavy use of classes and such. The source should prove useful to anyone looking to develop a kernel in C++, or any other OO language.

The kernel also provides support for 'service calls', which are sort of like APCs/DPCs in Windows NT. The only use for these at the moment is the user-mode page fault handler, which is demonstrated by this release.

You can find the source and floppy image here:
http://sourceforge.net/project/showfile ... _id=151015

Also, a few notes about my design can be found on my wiki:
http://dyknl.sf.net/wiki

Thanks for reading,
Senaus

Hi, I can't get sources from this location.

viki wrote:Hi, I can't get sources from this location.

Did you try a different mirror? You can view the latest source via SVN at this address:

http://dyknl.svn.sourceforge.net/viewvc/dyknl/trunk/

Thanks,
Senaus

I've converted most of the code to C++, and I make rather heavy use of classes and such. The source should prove useful to anyone looking to develop a kernel in C++, or any other OO language.

I'm interested, I'm in the middle of a conversion...

Yes, it was your conversion that inspired me! It all went smoothly, but i was rewriting most of it anyway

I've done the same thing. I much prefer the feel of my kernel code in C++. The only thing that I have left 'C style' is my memory manager. Everything else has gone OO.

My SVN source tree is still a mess though ...

Same here, my scheduler, context switching & kernel memory manager are all still in C, for simplicity's sake. I used my changeover from CVS to SVN to sort out my tree

Hi,

At the risk of getting in to a C vs. C++ war, I was concerned about moving my scheduler over to start with too, but classes made it so much neater (this may be because I am used to OO, so my non-oo style could just be messy!).

Now I have an exefile class which loads all relocation information from a binary. This class can be used to seed a Task class, which sets up the memory space for the exe file and calls a Relocate() function in the exefile class. This means that task addition goes something like:
Where fileptr is the unrelocated executable in memory. Some people may not like this but it looks neat and maintainable to my eyes.

Certainly I agree that the memory manager does not necessarily suit class-based programming.

Adam

I don't see the difference between 'scheduler.AddTask()' and 'QueueThread()' for a single processor. The OO method would be cleaner if you had a separate queue for each CPU, e.g cpu[1].AddTask().

My classes wrap the lower level functions, so I can do: Which will call the following internally: At the moment, my scheduler only has two routines (kDoSchedule() and kQueueThread()), so OO seems like overkill!

Cheers,
Senaus

What compiler are you using? I'm using DJGPP but templates don't work in it, which is really frustrating because I wrote a linked list class to save writing the same code over and over again. Unfortunately, it doesn't work...

Did you just make a cross-compiler in Cygwin?

I'm just using native GCC on Kubuntu Linux. Works a treat for me so far

Cheers,
Senaus