ORG, GEN Re:arf2 [djg12]

[Dennis Marer]

> It really sounds to me like you are saying that now that discussion of
> the general design is diminishing that it is time to begin coding.
> 
> Please,
> 
>         NNN      NNN      OOOOOOOO      !!!
>         NNNN     NNN     OOOOOOOOOO     !!!
>         NNNNN    NNN    OOO      OOO    !!!
>         NNNNNN   NNN    OOO      OOO    !!!
>         NNN NNN  NNN    OOO      OOO    !!!
>         NNN  NNN NNN    OOO      OOO    !!!
>         NNN   NNNNNN    OOO      OOO    !!!
>         NNN    NNNNN    OOO      OOO       
>         NNN     NNNN     OOOOOOOOOO     !!!
>         NNN      NNN      OOOOOOOO      !!!

No is correct!  The design has only just begun.

I think what Andreas is suggesting is to streamline things a bit!  As much as
I'd like to jump in and start actually writing the kernel or the OS, I don't
have the slightest idea where to start yet.

> The design phases are:
> 
>         1) requirements
>         2) general design
>         3) detailed design
>         4) coding
>         5) testing
> 
> Now I will admit, phase 1 is done.  Our requirement is for a "Multi-
> tasking Object oriented Operating SystEm" (thus MOOSE).  But we
> haven't yet managed to finish the general design, so we should at most  
> be doing some preliminary work on the detailed design and coding
> experiments that are considered, in the long term, junk; but WE AREN'T
> READY TO CODE.

I agree.  Phase 2 needs a lot more work still.

> I will admit that I, and probably most good programmers, have skipped
> both the general and detailed designs on numerous occasions, but that
> is for small projects of not more than two people and relatively short
> duration.  Lets not make the mistake of thinking it works for large
> projects!  IT DOESN'T!  At least not unless you plan to do it over.

I know that from experience too!

Let me let you know what I've been working on:

I've been developing little code 'snippets', or just little bits of code which
do useful things.  For example, I've written a program which initializes
protected mode on the 386.  Also, I've written some basic serial port device
drivers.  Also, boot from the hard drive and modifying the boot sectors.  In
the end, experience from doing this will go directly to this project - none of
the code will probably be used verbatim, but it will be used as a reference.

About the "mucketymockup" (I like that!) of the kernel in C++.  As I've been
writing the specs for the kernel, I've been testing what I've written.  I've
found from experience that lots of things look good on paper, but once built
don't fly and need to be redesigned.  To combat this, I've developed a *very*
simple "kernel" from which we can build and test ideas as they come up to see
if they are at all useful.  It does not use protected mode or virtual memory,
but it incorporates some of the ideas we've been talking about, including
*multitasking*!!!  This is only an idea testbed.

This by no means is the finished product - it's a device I've been using to 
test out what we've been discussing.  So far I've found 3 or 4 errors in logic
when defining the kernel on paper, and gone back and fixed them.  I feel its
better to find these *now* before we actually try to implement the real thing.

I agree with David - we're still only on Phase 2 (general details).  If we try
to start coding now, we'll be cutting our own throats.

> ======
> 
> I would say that what we need to do now is determine:
>    1) What the kernel will do and what the rest will do.
>    2) How messages will be sent to objects.  (This has been called
>       ROI.  PLEASE don't think that means it is seperate from the
>       kernel.)
> This more or less defines the kernel.
> 
> Then we get then detailed design:
>    1) What are the classes?  Most of the class hierarchy?
>    2) What are the common methods?
>    and about 10 times more stuff, most of which probably won't be
>       obvious until we get there.... (or even into coding....)

I've defined a lot of this in the next revision of the specs.  Actually, so far
I have only been working on the kernel specs, leaving the rest of the system
out of discussion for the moment.  I'm sorry these specs are taking so long,
but its been kindof a stressful time for me, both in work (real job) and my
personal life.  My time is more flexible from now on, and I'll be able to
commit a lot more effort towards our goals.

> AFTER that we code.

But I strongly recommend getting familiar with some of the hardware we'll be
working with.  Everything takes a couple of tries (IMHO) to get right, so if
you sat down and started writing a SCSI driver with no previous experience,
it probably wouldn't work very well.

I do have an excellent recommendation in this area - "Linux" already has many
common PC devices implemented, and would be a good reference for any disk drive
or even SCSI drive details.  Last I heard it supported many common devices -
there is no reason to ignore this source of information.  Just don't copy code
or we'll be bound by the Gnu copyleft.

I'm putting together ideas on how to further organize the kernel development.
We'll get together later this week to speed things up and get those ideas out
there and on paper.  Keep in touch!

			Dennis