Roll Your Own UNIX Clone
jamesmolloy.co.uk
Roll Your Own UNIX Clone
1–10 of 44 posts
Re: Roll Your Own UNIX Clone
#2Writing a kernel is fun... I started writing one a few weeks ago. It's not a real one, just something to play with. But it's very interesting, probably because I'd never worked at such a low level before.
Great resource: http://www.osdev.org/
Re: Roll Your Own UNIX Clone
#3I'll just leave these here...
http://www.intel.com/products/processor/manuals/index.htm
[disclaimer: I'm an OS/kernel dev]
Re: Roll Your Own UNIX Clone
#4Do it! By all means, really, seriously. You'll learn more about coding complex systems than any other project you've ever done.
It's absolutely doable.
If you want to make your life easier go for a micro kernel with message passing. That will partition the tasks to the point where a single determined person can go all the way from MBR to prompt.
Runner up in the experience category: make a game from scratch that has multiple threads of execution, but use a single threaded process. That's almost the same experience but completely in userland, which should make your debugging life a lot easier.
But if you want to learn all there is to know about memory management, interrupts and interfacing with hardware as well as process scheduling build a kernel.
Older dr. Dobbs issues contain tons of useful information.
Here is some food for thought: http://ww.com/task.cc.html and http://ww.com/task.h.html
Other sources of inspiration: the early minix kernels and the early work on what is now known as FreeBSD by Bill and Lynne Jolitz (also described in dr Dobbs iirc)
Re: Roll Your Own UNIX Clone
#5Do it! By all means, really, seriously. You'll learn more about coding complex systems than any other project you've ever done. It's absolutely doable. If you want to make your life easier go for a micro kernel with message passing. That will partition the tasks to the point where a single determined person can go all the way from MBR to prompt. Runner up in the experience category: make a game from scratch that has…
If you want to make your life easier go for a micro kernel with message passing. That will partition the tasks to the point where a single determined person can go all the way from MBR to prompt.
I don't know if I'd say that... For one, unless you are actually going to build vdevs and stuff any kernel you build is going to be a microkernel. In my experience, however, I would not say that message passing makes your life that much easier. In addition, it's probably a good idea to write an ELF compatible OS if you want a prompt. Writing a shell isn't that hard, but I wouldn't want to replicate the basic userland tools if I can just statically compile a busybox library. You should also plan to implement some sort of ramdisk if you want a useable environment (or virtual devs with drivers, but that would probably be harder). Actually, I'd recommend just building off QEMU, since that'll give you rudimentary device framework and keep you from having to debug on physical hardware (like I do).
Re: Roll Your Own UNIX Clone
#6Do it! By all means, really, seriously. You'll learn more about coding complex systems than any other project you've ever done. It's absolutely doable. If you want to make your life easier go for a micro kernel with message passing. That will partition the tasks to the point where a single determined person can go all the way from MBR to prompt. Runner up in the experience category: make a game from scratch that has…
If you want to make your life easier go for a micro kernel with message passing. That will partition the tasks to the point where a single determined person can go all the way from MBR to prompt. I don't know if I'd say that... For one, unless you are actually going to build vdevs and stuff any kernel you build is going to be a microkernel. In my experience, however, I would not say that message passing makes your li…
Message passing will make the kernel dead simple, after that it is all userland. This makes it much much harder for one device driver you're writing to crash another (or the kernel) by data corruption. A simple post mortem crash inspection will tell you what went wrong. Instead of doing the same on a whole kernel you'll just have that one little process that goes under, and the rest of the machine is still working.
I don't think I could have ever gotten my little OS to the self hosting stage without that.
It still took more time than I care to remember though :)
A virtual machine is a great tool as well, especially if it gives you access to the cpu contents of the running VM.
That will save you days if not weeks trying to find out why your switch from 'real' to 'protected' mode during the boot didn't work...
Re: Roll Your Own UNIX Clone
#7Earlier quoted context omitted.
If you want to make your life easier go for a micro kernel with message passing. That will partition the tasks to the point where a single determined person can go all the way from MBR to prompt. I don't know if I'd say that... For one, unless you are actually going to build vdevs and stuff any kernel you build is going to be a microkernel. In my experience, however, I would not say that message passing makes your li…
Message passing will make the kernel dead simple, after that it is all userland. This makes it much much harder for one device driver you're writing to crash another (or the kernel) by data corruption. A simple post mortem crash inspection will tell you what went wrong. Instead of doing the same on a whole kernel you'll just have that one little process that goes under, and the rest of the machine is still working. I…
Yes, that's why I recommended QEMU (which is a fast system emulator). A simple postmortem crash inspection will tell you what went wrong anyway. Simply write a normal micro handler to dump the registers at the end. Since you have the RIP, just objdump your binary and read the assembly from where it took the #GP or #PF. If you blew the stack away, you should automatically know from RSP, etc, etc.
Kitten[1] is the LWK which I work with, although my focus is on the Palacios VMM. It's quite a simple OS that is by no means out of a good programmer's reach.
Re: Roll Your Own UNIX Clone
#8Writing a kernel is fun... I started writing one a few weeks ago. It's not a real one, just something to play with. But it's very interesting, probably because I'd never worked at such a low level before. Great resource: http://www.osdev.org/
OSDev and OSDever ( http://osdever.net/ ) are both great resources in general, but I can't help but mention #osdev on Freenode. Incredibly useful resource if you're in need of assistance.
Re: Roll Your Own UNIX Clone
#9I'll just leave these here... http://www.intel.com/products/processor/manuals/index.htm [disclaimer: I'm an OS/kernel dev]
But you can bootstrap a cheap Unix with chapters 5-10 of this:
http://www.logix.cz/michal/doc/i386/
Getting into protected mode and exec'ing processes in their on private space has been done with ~4 pages of asm.
Re: Roll Your Own UNIX Clone
#10I'll just leave these here... http://www.intel.com/products/processor/manuals/index.htm [disclaimer: I'm an OS/kernel dev]
I gotta ask...if I go do this sort of thing on my own, I might produce something that won't segfault or oops()...if I were to walk into a job interview for an os/kernel dev job (the kind that rand say I did write a crappy primitive kernel would that look good or bad?
I've been working for almost 3 years now and this is an area that I would like to move into.