Re: ADA os talk

["McDoobie" <chris@dont.spam.me>]

In article <9mj1l3$1mn$1@nh.pace.co.uk>, "Marin David Condic"
<dont.bother.mcondic.auntie.spam@[acm.org> wrote:

> Allright - if you say so. :-)
> 
> Quite honestly, you are now outside my circle of experience & buzzwords.
> NUMA is a dangling pointer. So I guess I'll just agree and look smart by
> association. :-)
> 
> IMHO, a basic Ada kernel is most likely to end up running on a single
> processor, but why build in that limitation? IIRC, early versions of
> WinNT Workstation would support up to 4 processors - don't know what it
> does now. Why not 65536 processors? You'd not likely get there -
> discovering that the overhead bogs things down at some point, but why
> build in that limitation? While we're at it, why not make it a
> distributed kernel so it could be run in a box with, say, 4 processor
> cards each with their own memory and with shared memory & communication
> channels between them? Designs for such OS's exist & it would seem to be
> a good thing to adapt that capability into an Ada OS. It ought to scale
> with the app, or is it impossible? (Sort of: "If you've got one
> processor/memory compile/boot this way. If you've got N
> processors/memories, compile/boot this way...")
> 
> Maybe the best strategy would be to identify someone's OS college text
> as the starting point. If they describe some set of OS's in sufficient
> detail, it would be a matter of saying "We need to implement chapters 3,
> 7 and 12 of this text." The basic requirements would thus be done and a
> good part of the design work is right there. Any suggested books?
> 
> MDC
> --
> Marin David Condic Senior Software Engineer Pace Micro Technology
> Americas    www.pacemicro.com Enabling the digital revolution e-Mail:   
> marin.condic@pacemicro.com Web:      http://www.mcondic.com/
> 

Why even stick with those limits. Why not run the OS over a network with
'Disk' I/O node and a  CPU I/O node (could be a seperate server), et... To
the apps, it would just look like one huge computer.

McDoobie chris@dont.spam.me