Assumptions about non-x86 hardware

[paulbarker]

That is the general plan at the moment, but I want to split the kernel into arch-dependent stuff and generic stuff so that its not too difficult to port. I doubt I'll be doing the ports but I dont want to make a design that cant be ported to an architecture that someone wants to add support for.

If that makes sense

[Solar]

I want to split the kernel into arch-dependent stuff and generic stuff...

That would require knowledge about every single architecture that system will potentially be ported to, including as-yet-unreleased architectures.

I believe a better approach is to follow good design principles - abstract, modularize, document - and worry about portability when you have a specific architecture in mind.

[paulbarker]

The generic code will rely on a well defined interface provided by an arch-dependent layer. Whats wrong with that?

Linux does it, Windows does it with the 'HAL' and most other portable OS's do it.

The point is not to deal with every single eventuality, its to start now so that later changes to make the kernel really portable are small details rather than a huge overhaul.

My original idea was to force the kernel to be portable by supporting 3 platforms from the start (x86, MIPS, x86_64) but I think thats overly ambitious. I'm sticking to x86 for now, but an OS confined to a specific architecture will (almost) always die with the hardware. I really want to avoid that.

EDIT: Windows does it and thats not even a portable OS anymore!

[Solar]

The generic code will rely on a well defined interface provided by an arch-dependent layer. Whats wrong with that?

Nothing, that's not what I meant. (And I didn't mean any offense, either.)

What you describe is a horizontal isolation: What's below the HAL is platform-dependent, what's above it is generic.

What I meant is a vertical isolation: This is the memory manager, this is the scheduler, this is the dispatcher.

The two aren't mutually exclusive, to the contrary, they complement each other beautifully.

[paulbarker]

I did slightly mis-interpret your comment, but no offense taken, things never come across quite right in plain-text anyway.

I'm on my 4th or 5th re-write now anyway, so I'm dropping the MIPS platform I was having trouble with. This one isnt so much a re-write as going over each existing file and making sure its right before putting it online. I've now got a sourceforge project page and at least another week of unemployment where I can work on this. I'll post an announcement and a link as soon as I get something up thats more than the initial "Hello, World!" kernel.

[Solar]

Uh yes, I know that stage.

For example, I'm about 80% done with <stdio.h> in my PDCLib, and expect release v0.5 shortly after Easter. But there are literally several dozen "TODO" comments in there, and I will have to revisit every test driver and every header and refactor about 25% of the code before I will be even considering an alpha release.

Good to hear there are more developers like that out there - too many in the business confuse "working" with "good".

[paulbarker]

I have a general plan, I've probably mentioned it before and it may well end up as my .sig:

1) Make it work.
2) Make it work well.
3) Make it fast.

I think thats self-explainatory, and I consider it to apply to all software and electronics projects I do. Step 2 is about correct implementation, stability, security and being capable of dealing with all valid input.