From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <7f6f168f5d8ed3ddd20ffc2bd069d95e@terzarima.net> To: 9fans@cse.psu.edu Subject: Re: [9fans] GNU binutils: you can't make this shit up From: Charles Forsyth Date: Thu, 19 Jan 2006 10:34:09 +0000 In-Reply-To: <20060119082946.19064.qmail@web32707.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: dfce65c2-ead0-11e9-9d60-3106f5b1d025 > There is something to be said for microkernels > they allow for a lot less headaches with kernel > development, and it could drastically improve plan 9's > portability, a key feature. term% pwd /usr/forsyth/src/xen3/xen-unstable/xen/arch/x86 term% wc -l mm.c shadow32.c shadow_guest32.c 3519 mm.c 3397 shadow32.c 18 shadow_guest32.c 6934 total # and that could be the tip of an iceberg, since that's x86-only # now let's look at several non-micro/hyper kernels term% cd /sys/src/9/pc term% wc -l mmu.c 1043 mmu.c term% cd /usr/inferno/os/pc term% wc -l mmu.c 321 mmu.c now if you're using the first implementation above, you still also need something like the second or third as well (but a little different). that's a hypervisor (but one that is claimed in a paper to be `microkernels done right'). its code is much bigger because it actually does much more than 9's or Inferno's. i'm sure last time i looked (which to be fair was years ago) mach had quite a bit of complex mmu code too. which is likely to give you more headaches, and how strong? perhaps we should have an ibuprofen rating for kernels? portability? i have done kernels (including small micro-ish ones) myself, and i have worked with other systems extensively over the years. in my experience, some of the interfaces the micro/hypers present is HARDER to drive than the underlying hardware, possibly more frustrating, not as well documented, and changes. and of course there's more code in the end. somtimes much more. it wouldn't be so bad if people hadn't forgotten an important lesson from THE: the idea is for each layer to provide increasingly higher levels of abstraction, the better to reason about. of course, in several cases, the newer systems are the way they are to make porting Linux easier (well, that's my impression), presumably on the grounds that its interfaces are all over the place, x86-oriented, and hard to change. then there are the interfaces for device drivers... not that i'm bitter. the way to get good portability is to have clear, well-designed interfaces that abstract away from hardware peculiarities, and map those to the hardware (rather than, say, reflecting in the interfaces the union of every peculiarity of all hardware known to you at the time). some of the hard bits about kernel development are: - getting accurate documentation for the processor, devices, existing bootstrap, etc. - getting anything loaded into the wretched machine at all - deciding how your kernel should look, what it should do, how it should change - working out a good infrastructure for networks, devices coming and going, power, etc. - finding time and/or money to do any of it now, while it can be really tedious when you get yourself into the state where the hardware resets without notice (and worse, takes quite some time to get to that state, or requires ... something ... but what is it???), it often isn't something that would be fixed by a micro-kernel, but rather by better hardware, documentation, more careful coding, fewer interruptions, more time to think, more energy, and of course more intelligence. lacking any or all of these, it's still usually easier to debug a component of a smaller system with a straightforward model overall. that might be true of some micro-kernels, but not all, and it isn't limited to them; a more `conventional' kernel can be quite acceptably modular.