Moose Revision 0!

[Dr. Hayden]

Howdy Moosers!

I like revision -72 a lot, except for some areas that seem to conflict
somewhat.

First off, there is a mention of how we're aiming to support the 2-8MB
RAM PC market, yet we want multi-user support.  8MB, in my estimation,
seems a little bit small for multiple users.  And, does it seem we
need multi-user support in the PC arena anyway?

Also, should we take into consideration the design of the Motorola chips
before we begin?  I say this because I know the 386 much better than the
680X0s, and I'd like to follow the task and memory management facilites
provided by the 386 as closely as we can; however, if the two
architectures differ significantly in those areas (say, if the 680X0s
don't have any hardware task switching capabilities), then maybe we
shouldn't use the 386 facilities either.  It seems there may have to be
a balance struck between the two architectures (unless we just want to
write it for the 386, then port it later).  My envisionment of Moose is
that, on the PC end anyway, it will be primarily interrupt driven.  I
don't think we can do it that way on the 68000 series.  This is a
fundamental difference, and this alone could cause us to essentially
have to write two completely different kernels which may not support all
the same features between them.  The main question I'd like to ask of
all of us is this: do we expoit the 386 for all it has, or do we look
for a least common denominator between the two architectures and aim
for that?

Also, our OS will not run on anything less than a 386SX, so is there
perhaps a similar cutoff in the Motorola chips.  I mean, is there such
a difference between, say, the 68020 and the 68030, that we should not
develop for anything less than the 68030?

And, about Mac support, isn't the user interface part of a Mac OS in
ROM?

Section E concerns scheduling.  I'd like to see four priority classes.
We could have a time-critical class, then perhaps some type of
class where we could let threads run that need to run before those of
a user class, such as server maintenance threads and the like, then of
course a user class, and finally a daemon or idle thread class.  Within
each priority class we'd have just a simple round-robin dispatching.
Sound like it will fly?

Anyway, I've talked on a low level here, but I think there a some very
low-level questions such as these that need to be considered early on,
just as those high-level design considerations.

Thanks,
Ross Hayden
haydedr@wkuvx1.bitnet