Organization [dpm1]

[Dennis Marer]

Greetings Moosers!

The intent of this message is to expand on the organization efforts started by
Andreas - the focus of our efforts will shift a bit in the next few weeks,
which will give our brains a chance to think about something different.

-------------------------------------------------------------------------------

First, a suggestion.  We've been tossing around naming ideas for a while now,
and eventually decided to not try and name the operating system until it has
been better defined.  I agree, but do have one suggestion:

Why don't we call the kernel "Moose"?

I really like this name, and it captures the spirit of this project I've seen
so far.  (One big ugly beast?)  Anyway, none of the end users will care what
the kernel is called (or even if there is a kernel there) so I think its a
perfectly acceptable name.  Or, for the international faction, "Elger"?

Howzat sound?  (Look, a Moose smiley!---->   C:{  )

-------------------------------------------------------------------------------

Here's our plan of action for the next few weeks: we've generated a lot of
great ideas for the kernel, and its time to put all those ideas into a single
document.  That's what I've been working on for a while, and will continue to
work on until it's been finished, which could take another week or two.  I've
got over 1 megabyte of mail to sift through, so this is a long process.  I
feel after we've got something definite on paper, we'll be able to discuss it
in a more organized manner.

For example, when you feel changes need to be made, refer to the document:
"Chapter X, Section Y, Paragraph Z: I suggest..."  Without a document, there
is no record of the decisions made, or how they affect the rest of the system.

Some of you might have questions about why one person (me) is in charge of
the kernel at this stage.  This is because most of the details concerning the
kernel have already been discussed and they need to be written down, and
it won't be possible for us to collaborate on this task.  Obviously, this
might produce a document which looks like the kernel in Dennis' eyes, but I'm
trying to be objective and adding your needs and concerns as well.

If you're worried about me just having you as free coding help, don't.  I'll
probably want to do all that myself too.  :-)  Actually, no...I think coding
the kernel will be something much easier to collaborate on, and we'll be able
to split up tasks into logical, predefined sections, as described in the
specs we're working on now.

-------------------------------------------------------------------------------

My plan is set for the next couple of weeks, and I'd like to shift gears a bit
and set you all into a different line of thinking for a while.  At this point,
I'd like to ask you to trust me and assume the kernel is defined enough to the
point that we may start design of the rest of the system.  I'd like to turn
your brains away from the kernel for a short while and start thinking about
what resides on top of it.  Namely, as Andreas suggested, the devices.  I've
grouped things together more into related areas, as shown below:


User Input Devices
------------------

    Text input (keyboards, speech recognition)
    Position input (mice, touch screens, etc)

User Output Devices
-------------------
    Video output	
    Hard copy (Printers, plotters, faxes)

Mass Storage Devices
--------------------
    All types of disk drives (low level block access, floppy, hard, networked)
    Filesystems (HPFS, DOS, etc, etc, ???)

Communication Devices
---------------------
    Serial
    Parallel

Networking Devices
------------------
    Networks

Maybe I'm missing a few, or the groupings aren't quite right, but that's not
too important.  What is important is the concept of a device as an object, and
how it is similar to objects in its group.  For example, why could both the
serial and parallel devices utilize the same interface?  Each would be a
descendant of some 'communication device' object but implement its methods in
a way pertinent to itself.  Similarly, both hard copy and video devices might
share the same interface to simplify WYSIWYG output when the GUI is developed.
(Oh...I didn't put the GUI on here because its not a device.)

Here are some of the steps I see in defining device objects:

    1. Classification (Single vs. Multiple user)

	Can this device be used by more than one user at a time?  A serial
	port, for example, could only support a single user which greatly
	simplifies its interface and internal workings.  Disk drives need to
	be accessed by multiple users, so their interface needs to accomodate
	these needs and their internals become much more complicated.

    2. Relation to other devices

	How would this device work in conjunction with other devices?  Would
	it use other devices?  Would other devices use it?  How similar is it
	in functionality to other devices?  For example, a network device might
	be able to use either a standard serial port or FDDI hardware without
	changes to its internal structure.  This would be both of these types
	of communication devices should be designed with identical interfaces.

    3.	What special needs does the device have?  Can these be accomodated by
	the generic kernel or do special extensions need to be built in?

    4.	How will device contention occur (transparently to the user) in multi
	user devices? 

    5.	What will the interface to the device be?  For data transfer devices
	will this be block or stream oriented data?

    6.	How can devices with similar interfaces be better grouped together to
	minimize our work?  For example, could all data transfer devices (like
	disk drives, and network devices) use a common ancestor to handle some
	of the more common functionality?

Just thinking about it, here's a sample heirarchical structure of devices. I
just spent a few minutes on this, so its nothing concrete, just an example of
how things might be structured:

	device
	    dataTransfer
		blockData
		    massStorage
			floppyDrive
			fixedDrive
			    Winchester
			    SCSI
			    networkDrive
			    etc.
			CD-ROM
			floptical
		streamData
		    communication
			serialPort
			parallelPort
			modem
	    userInput
		characterBased
		    keyboard
		    voiceRecognition
		positionBased
		    mouse
		    touchScreen
	    userOutput
		hardCopy
		    printer
		    fax
		video
		    VGA
		    superVGA
	    audioOutput
		sampled
		    soundBlaster
		note
		    MIDI
		    etc...

Does anybody want to officially document this structure and keep it current?
Or restructure it?  Like I said, I only spent a few minutes on it...

-------------------------------------------------------------------------------

What I need you to do is to pick one of these areas and begin to design its
interface.  To do this you'll need to coordinate your efforts with those
devices in similar areas or with similar functionality to insure your
interfaces are compatible.  Andreas has already started taking volunteers for
each section, (and we're missing a lot of people) so sign up now or the rest
of us will have to take on multiple interfaces.

>From these designs, I also expect you to write a "chapter" in what will
eventually be our user documentation.  Don't worry right now about proper
English or organization, content is the most important for the time being.
Write down your definition of a particular class of objects, as well as how
it interacts with the rest of the system, and (finally) its interface.  Be as
complete as you can be!

If you're absolutely not interested in device drivers, say that too but come up 
with some suggestion of what else needs to be done.  Here's a partial list I 
can think of:

	GUI/TUI (Graphics/Text User Interface)
	User and session management, access rights
	Filesystems
	Languages

Any questions so far?  Just trying to divert your brains from the kernel long
enough for me to put it all down on paper.  Hopefully by the time I've finished
the kernel docs and mucketymockup, you'll have made enough progress on your
respective device so that you can implement a mockup of it as well and test
how it functions under the mockup.  This section will be individual work
mostly, but need lots of discussion among the group to coordinate how each
of our devices are used.

My dream is that we've defined and tested every aspect of the system before
we even attempt to implement it.  You don't think Intel developed and built
the Pentium processor without simulating it first, do you? :-)

		Dennis