[9fans] first casualty of the spam-forced restrictions?

[9fans] first casualty of the spam-forced restrictions?

[andrey mirtchovski]

this message sent to comp.os.plan9 never made it to the list:

	http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&group=comp.os.plan9&c2coff=1&selm=pan.2004.07.27.10.31.49.758185%40Utel.no

i'm only posting this because it makes an interesting, unheard thus far,
claim about the source code of the OS :)

andrey

Re: [9fans] first casualty of the spam-forced restrictions?

[Bruce Ellis]

that's a joke!  the mmu code is very-very clean.
that's why it worked first day on olive (correct
me if i'm wrong jmk) on an early unknown quad xeon.
things changed but only for the better.

i remember it was initially running for over
3 months unattended - but of course you want your
new kernel booted eventually.

brucee

* gcc makes me want to smoke crack -- beck

andrey mirtchovski wrote:

> this message sent to comp.os.plan9 never made it to the list:
>
> 	http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&group=comp.os.plan9&c2coff=1&selm=pan.2004.07.27.10.31.49.758185%40Utel.no
>
> i'm only posting this because it makes an interesting, unheard thus far,
> claim about the source code of the OS :)
>
> andrey

Re: [9fans] first casualty of the spam-forced restrictions?

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 1164 bytes --]

i suppose he'll have to subscribe to the list.

one difference in the plan9 code from the xbsd and especially lunix approach is that
the mmu code starts with the view that the system software thinks it would like
and gets the hardware-specific code to implement (just) that with the
actual hardware, rather than pushing a clutch of hardware-specific (sorry, x86 or vax or sun)
properties and data structures throughout the rest of the kernel.

it makes porting easier because there's less handbook to fuss over.
i look (say) at pages and pages of complex data structures for arm, sparc, and powerpc
mmu descriptions, often different in each revision,
and i am grateful i need only locate the tiny subset that i really need to use.

of course, as with compilers or anything else that needs a
portability interface, if there's an enormous mismatch between the
portable code and a particular platform, you need to decide whether and what to change,
but you still retain the software-oriented structure.

in some cases, it's worthwhile completely ignoring the `clever' mechanisms
the hardware designer provided, and just programming what you need.

[-- Attachment #2: Type: message/rfc822, Size: 3304 bytes --]

From: Bruce Ellis <brucee@chunder.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] first casualty of the spam-forced restrictions?
Date: Wed, 28 Jul 2004 19:10:24 +1000
Message-ID: <41076D80.6070304@chunder.com>

that's a joke!  the mmu code is very-very clean.
that's why it worked first day on olive (correct
me if i'm wrong jmk) on an early unknown quad xeon.
things changed but only for the better.

i remember it was initially running for over
3 months unattended - but of course you want your
new kernel booted eventually.

brucee

* gcc makes me want to smoke crack -- beck

andrey mirtchovski wrote:

> this message sent to comp.os.plan9 never made it to the list:
>
> 	http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&group=comp.os.plan9&c2coff=1&selm=pan.2004.07.27.10.31.49.758185%40Utel.no
>
> i'm only posting this because it makes an interesting, unheard thus far,
> claim about the source code of the OS :)
>
> andrey

Re: [9fans] first casualty of the spam-forced restrictions?

[Rob Pike]

i agree. i think the way the MMU is handled in a portable way
is a model of how to do this stuff.  the interface to the rest
of the kernel is only a handful of routines with very specific
properties.  implement them and your system will run.

we've had to adapt the interface a little over time, such as
when page coloring came in for virtual caches, but even
there, the very narrow interface made that easier.

i remember SGI had a 40-page memo on how they implemented
VM on the power series machines.  our MMU trap code was
somewhere close to 40 lines of C.  we weren't quite as
general (there was no way in plan 9 to shrink an address
space), but the lack has never been an issue in practice.
plus, our interface has been ported all over the place; i suspect
IRIX was a little trickier to move to the challenge and then
to the x86 machines.

-rob

Re: [9fans] first casualty of the spam-forced restrictions?

[boyd, rounin]

> i agree. i think the way the MMU is handled in a portable way
> is a model of how to do this stuff.

absolutely.