Roll Your Own UNIX Clone • Hacker News Board

Re: Roll Your Own UNIX Clone

#41

Post by michael_dorfman » Tue, Aug 04, 2009, 7:06 PM UTC

Locke1689 wrote: post #40

michael_dorfman wrote: post #39

Earlier quoted context omitted.

Outdated? I thought the Linux Kernel was outdated in comparison. The Minix kernel was rewritten from scratch in 2006 for version 3.

OSDI (2nd) was written in 1997, perhaps you were thinking of this? http://www.amazon.com/Modern-Operating-Systems-3rd-GOAL/dp/0... Minix 3 is a whole different ball game though. It's an interesting kernel with some interesting ideas, but I still recommend Linux as it's both more popular and reflects the majority of UNIX design decisions today. Even the OSs with praise for microkernel design tend to incorporate a numb…

The 3rd edition of OSDI is definitely worth reading. The MINIX3 kernel is only 4000 lines of code; very clean, and easy to wrap your head around.

Re: Roll Your Own UNIX Clone

#42

Post by JamesM » Sun, Aug 09, 2009, 12:57 AM UTC

dkersten wrote: post #18

Thats great and all, but hes forgetting two very important aspects of a real OS: drivers and software. Ok, hes not building a real OS, but rather a toy OS (presumably for the learning experience), so these things are not so much of an issue. Its actually a good article, IMHO, and I wish it had been available a few years back when I tinkered with writing my own toy kernel. The "Roll your own unix clone" title given he…

I wouldn't say it was misleading - the front page of the article clearly states that a kernel is being developed. Drivers and software belong in the rest of the operating system. Given the availability of GNU software, a UNIX userspace is fairly easy given a smallish set of system calls.

Yes, I'm the article's author. Yes, I'm biased.

Re: Roll Your Own UNIX Clone

#43

Post by JamesM » Sun, Aug 09, 2009, 12:58 AM UTC

GeneralMaximus wrote: post #15

Whenever I think about doing something like this, I always get stuck up on x86 ASM. There don't seem to be many books on ASM out there, and the ones I could find in the bookstores were all written around MASM which, of course, does not work on Mac OS X. Any ideas?

The Netwide Assembler (NASM) which I mention in the article frontpage has the same syntax as MASM without the nasty licence. Some of the assembler directives may differ, but 90% of your program will be identical.

Re: Roll Your Own UNIX Clone

#44

Post by JamesM » Sun, Aug 09, 2009, 1:06 AM UTC

asciilifeform wrote: post #20

Please don't! Build something original . It really is possible! Once you've built a UNIX clone, you have polluted your mind as an OS designer. I did so (as a standard college homework assignment) and it took me years to shake the crud out of my head. As for the tutorial, it is very well written, but x86-32-centric and therefore worthless. There are nontrivial differences between x86-32 and x86-64 from the standpoint…

As to your previous point, the tutorial series is aimed to be one thing and one thing only: A set of tutorials to help bridge the gap between the practical and the theoretical as far as OS implementation is concerned.

There are plenty of tutorials on ASM coding, and plenty on low-level C coding. There are plenty of books about OS internals. The books and articles I've found before tend to stay firmly in the theoretical, in the abstract. The aim of this series is to show how the theory can be implemented. Then, the reader has the knowledge to (possibly) implement their own algorithms and know how they link to the CPU's internals.

As to your second point - do you think that the memory manager in this OS is optimal? Do you think that the linked-lists everywhere are optimal? Of course not. Everything was chosen for its simplicity - I failed in some areas I know, and I'm rewriting them as I speak (they're stalled at the moment due to a lack of time); the heap for example is a mess in that series. The new one is much easier to understand.

The series does not create an optimal OS for IA32. So your point about transitioning to amd64 to "make full use of the latter's capabilities" is moot - you have to do more research to optimise for IA32 anyway, let alone amd64!

(And let's not forget that all amd64 CPUs are backwards compatible with IA32).