OSDev.org

If we ignore bootloaders, most of us probably start from building a kernel that loads successfully, then prints something like "Hello World!". Then we start messing around with memory management, first physical pages, then virtual ones. At this point we also need interrupts. Some of us then proceed with basic device drivers, or maybe userspace....

What I'm wondering, has anyone here tried writing a kernel on top of a host-system, and only gradually moving it to bare hardware? Obviously there are quite a few things you can't do when running under another OS, but many things could be simulated, and debugging might be easier?

If someone has done this, could you offer some insights? How did it work? Do you think it was good or bad idea? Why?

For the rest of you (and if nobody's done this), does it sound like a braindead idea, and if so, why?

mystran wrote: For the rest of you (and if nobody's done this), does it sound like a braindead idea, and if so, why?

I think this is a great idea. However, what OS will allow this to happen? I kind of expect perhaps someone elses shell maybe?

Ther are emulators for this pupose they allow easy debugging and allow for quick testing as, in my case i just change the source code re-assemble, re-create floppy immage and thjen run it in BOCHS.

BOCHS is great and easy to use, its available for microshaft windows and linux...

Give it a try...

@mystran: do you mean something like Userspace Kernel? As far as I remember, there exist some "user space" linux kernels, but this is faint memory, so I 'd rather google for 'em ere I say it's the bare truth. Project AROS might be another approach to this, but I'm not sure.

But if yes, then nay, I have not yet done such a thing.

Braindead and sorta ... *rofl* as if we belong to the sort of ppl thinking of controverse ideas as "pah, thats a big load of bullshit, that lad shall go back to kindergarten". Nay, it's au contraire an interesting approach. Maybe it would be necessary to do the device access different - reading from raw /dev/fd0 might be as reading from floppy - you fetch blocks. hm ... just my brain rambling around.

@kieranfoot: I'd also recommend qemu. That's with less debugging facilities than bochs but quicker and much easier to handle.

well, parts of clicker have been developped in such an "in-linuxo" environment and then migrated to the real Clicker ... That includes the printing/formatting functions, memory management (somehow, allocators, bitmaps etc. can work in userspace too), the koLib (especially size-adjusting associative arrays) and the KDS subsystem...

not sure if this is relevant, as there isn't and won't be a kernel, strictly speaking...

i'm using an artificial, simulated instruction set. i have assembler, linker, simulator. a compiler (c/c++ replacement) is in progress.

once it is sufficiently complete, i will enhance the simulator to allow multiple processes, threads and their interaction with a "kernel" (simulator-controlling logic - simulated or host-native in c++).

then, i will start playing with OS design - plug in my text-mode gui engine, create filesystem services, etc. these can be simulated or host-native, mix and match.

that way, i can concentrate on the new OS components - usermode environment, system services, applications.

the resulting system can be ported to real hardware - either by writing/porting kernel, drivers, language runtime, or as a subsystem on top of some existing OS that is flexible enough to handle it.
applications should be immediately usable upon recompilation.

My boot loader loads a com/bin/exe file from the floppy.
So my kernel is a mz exe file, it starts in real mode and moves to pmode, i can run my OS from Dos or the bootloader noproblems, if i put the right code in the kernel to go back to real mode, i can come out of my OS to Dos.
Maybe i should rename my kernel win.exe, than at the dos prompt i can type win to go to my OS .

\\\\||////
(@@)
ASHLEY4.

Batteries not included, Some assembly required.

What I'm wondering, has anyone here tried writing a kernel on top of a host-system, and only gradually moving it to bare hardware? Obviously there are quite a few things you can't do when running under another OS, but many things could be simulated, and debugging might be easier?

In the current version of my OS, I wrote most of the code to be easily ported to other OSes. It relies on just a way to read the keyboard and display text to the screen for a minimal system. So I debugged everything from the user's perspective on Linux, FreeBSD, and Windows. Then I wrote simple screen and keyboard drivers and have gradually built up from there. Since it's a Forth system, much of the code could then be written and tested from this minimal startup.

The kernel really can't be written well while running over a host OS, but non-driver/architecture parts can be, and it really helps when debugging.

As for User-Mode Linux, it exists, and e.g. Gentoo supports it quite nicely: http://www.gentoo.org/doc/en/uml.xml

@solar: good link. Have given it a look and gonna try that thing out. *bowstosolar*

this is precisely what nachoes does, it is for developing a kernel entirely in user space (actually uses a mips emulator for user space i beleive)

it works entiurely on simulated hardware which is mapped to system calls and such. good for educational use, but not practical anywhere else.

proxy

I'm doing both. And more, actually.

I've got several 'projects' running, and they're all progressing quite slowly unfortunately, but it keeps my mind busy and if I'm stuck/bored with one, I can switch to another. The grand finaly is of course when everything comes together, but that won't be soon I think

My projects (from hardware to software)
* LA - Linked Architecture
Playground for creating an uniform interface between components, basicly designing thing The Way They Should Be. Since x86 is a nightmare, apple powerpc boxes are some serious black boxes, and sparcs suffer from firmware... Working ways out like fully automatic memory management by hardware.

* Perseus - Interprocess Communication Operating Environment
A blend of a temporary operating system layer on a x86 box, and a system that handles signals coming from and going to processes. Since memory management is somewhat ment to be fully hardware build, but x86 needs it, it's also running here.

* Wu@ - Where U At User Interface
Started as a modular chat client (where modules could be added for different protocols) but is currently a test field for how to handle everything like a module, and module - in - module trees. The graphical side of Perseus sort of speak.

* Cepheus - Artificial Intelligence Research
Oldest project of all, my attempts and tryout in the field of Artificial Intelligence. It has nothing really to do with the other projects, but sometimes gives quite interesting ideas on organisation efficiency of components, and LA protocols, Perseus and Wua all have ideas build in which originated from this project.

* Stuff - Using current hardware / software
Porting stuff to my projects. A bit of a research pile of paper spreaded through my room, with loads of wild in-between projects all to learn about the best protocols/interfaces/ideas/solutions this world has to offer and implement them into the other projects.

It sounds like a huge approach, but seriously, it works. Although you have to multithread between the projects and your spare-time is somewhat limited (like mine) you're not making that much progress in time, you do get a complete picture of everything you want and can do. Which keeps you going

- <wacco>

Sorry for not replying any sooner as I've been busy with other stuff. So, well, I'll just go over the interesting answers here quick:

- Yes, I do know Bochs. It's great. It's not what I ment. Instead, I actually ment something that does run as an userland process on top of another OS, directly without hardware emulators.

- Indeed, I have also though of self-hosting language, with minimal drivers once it's up and running. Forth is the easiest option obviously, but I think it's possible with much higher-level languages as well.

- I knew of Nachos, but I don't think it qualifies, as it's not designed to be a "state of art general purpose system" but rather an example and a teaching platform.

- As for architectures, x86 has it's oddities yes, and some of them do cause headache, yes, but I think there is a reason why it's the most popular platform: it scales damn well. Besides, I don't really think I miss the delay-slots and other oddities of Sparcs.