On Tue, Feb 2, 2021, at 8:29 AM, tlaro...@polynum.com wrote:
> > 
> > Plan 9-related:
> > 
> > (1) Porting the Plan 9 kernel to a microkernel architecture, such as
> >     Mach.  This would give Plan 9 instant access to the whole range of
> >     hardware supported by the underlying microkernel.

Apple's Mach is not a microkernel. The first pure microkernel version of the 
Mach architecture was 3.0. Apple have stuck with 2.5 all these years. The 
ability to use drivers from some more popular OS would be nice for users if it 
works, but there are a host of possible integration and maintenance problems. 
In fact, I know there are problems I don't quite understand related to 
differing OS designs. The parts I do understand indicate there could be a huge 
performance penalty in using drivers in OSs for which they were not designed.

I specifically say "more popular" because popularity affects the number of 
developers available. In those terms, 9front is already in the rarified 
stratosphere of well-developed hobby OSs. I'd put only 2 or 3 other OSs as its 
equal. In the next level up, (orbital space? ;) and not counting the BSDs, 
Haiku is the only one I can think of off the top of my head (but I have just 
woken up). We might yet see other OSs implementing 9p so they can use our 
drivers. :) 

> No. One should re-read the initial papers about Plan9. When Plan9 was
> designed, microkernels were "fashionable". If one reads carefully the
> paper, it's clear that there is a pun intended against microkernels that
> didn't achieve what they were supposed to do---disastrous efficiency
> leading to the rewrite of the microkernels as assembly---a very low
> signal/noise ratio. And a hint: "micro" kernels are usually _huge_, a
> clear sign that something went wrong.

Uh... these arguments are kind-of obsolete. Plan 9 is a hybrid on the 
macro-micro kernel scale. So are mainstream OSs, having arrived at that point 
by various routes from whatever their origin was. Microkernel QNX is tiny and, 
if I understand right, makes service development easier than Plan 9 does. I 
suggest the huge "microkernels" are really hybrids, but I'll omit reasoning on 
why.

> As drivers are concerned, there was once a kit supposed to give a wide
> range of kernels, drivers code---I don't know where it is now; I suppose
> it has vanished. And now probably UEFI drivers is a "better than nothing"
> solution.

Uh... UEFI boot services are typically available, but UEFI run-time services 
are a different thing. A long-time OS dev I know does not expect UEFI runtime 
services to ever be available on commercial-grade hardware. He is a terrible 
cynic and I can't remember quite how that debate ended, but in general, it 
looks like UEFI isn't significantly better than the old PC BIOS for 
compatibility. As they say on osdev.net, "Writing a bootloader which works on 
one computer is easy. Writing a bootloader which works on many computers is 
hard." Note this statement is only about features necessary for booting an OS, 
whether BIOS or UEFI. If those are bad, features not necessary for booting will 
be worse. And performance of the kind needed at run-time is hardly a 
consideration when booting. (I appologise for my poor sentence construction. 
I've just woken up.)

> My 2 cents,

Ain't the Internet wonderful? You get 2 cents back with a lot of interest! XD

Much of what I've posted here is condensed from osdev.net, especialy the 
forums. I'd suggest lurking there if you're interested in the difficulties (or 
otherwise) of driver development. It's not perfect by a long shot, but it is a 
better place for it than this list.

------------------------------------------
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T1c300cdbd9941edb-M1b3c27671fcffae2e5ffa604
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Reply via email to