Explanation

[Tom Novelli]

On Fri, May 28, 1999 at 02:08:26AM -0400, Maneesh Yadav wrote:
> THis is by no means an apology for my recent posts, but I would like to
> say that I hope I am not offending anybody, I am really just trying to
> kick some reality into some empty promises and possibly educate some
> people who, IMHO really haven't had any experience with and sort of real
> code development, let alone a project such abmition.  The differences in
> opinions are clear, some are saying that all the projects will eventually
> become integrated, other are saying TUNES is a discussion form etc...I am
> usually not one for strict definition in these things, but to really call
> yourselves a group and have goals like the ones posted on the web page and
> have n different projects and say that they will magically someday be
> integrated into one another all the while solving all the problems of
> software design in some finite amount of time is just plain lying.

Thanks for your realism, but your negativity isn't getting us anywhere. 
Luckily it's falling on deaf ears.  Anyway, for those who aren't experienced
in software development, this is a good opportunity for them to learn.  So
what if there are a few different "factions" within Tunes?  Eventually
they'll either merge together or split off.  Yeah, we'll never solve all the
world's problems but at least we're trying!

> I'm going to post a series of questions one the various project out again
> and I think for the sake
> of the group having an idea what is going on they should be answered,
> please no editorials jus simple short answers.

Allright, sounds good.  I'm sure it'll raise a few points I've overlooked.

> First of all, part of the TUNES project seems to be developing a
> microkernel in assembler (I'm looking at tcn).
>
> Ok,
> What advantages are there to using this kerenel than to use an existing
> one?

If you're referring to Linux or *BSD, those come with too much Unix
baggage.  When you start from scratch, you're free to try different ideas.

Keep *my* goal in mind: I just want a simple, fast, useful computer system. 
I don't need any fancy new ideas for that, I just need to keep it simple and
use common sense.  I may reinvent the wheel, or I may invent something new
without realizing it... I don't really care, as long as I reach my goal.

For me, Tunes is a further goal, something to work toward even after I've
reached my first goal.

> What language are you writing it in (assembler last I checked), how do you
> expect to port efficently?

The core is in assembler... porting it won't be that difficult.  Hardware
drivers are usually written in assembly too (for efficiency and control),
but other platforms have different hardware.  Also, I expect the assembler
code to shrink as the OS becomes high-level.  Much of the porting time will
involve writing a code generator for the new platform.  Another thing to
ease porting: translate the assembler code to high-level code (or pseudocode).

> WHat is you basic multitasking mechanisms (what data structures are
> involved, hardware/software,  priorities, timesclicing etc.)?

Currently, it's just a circular list of tasks, switching at fixed intervals. 
I plan to use a better structure at some point, probably a priority heap. 
Variable intervals are another possibility.  But these things can be easily
changed; they aren't tied to the rest of the OS.

> What does a task memory map look like (or the basic memory scheme in
> general, what parts of mem are shared, selectors, page granularity etc.?

I'm not nearly done with the Persistent Store, which will manage all forms
of storage.  Right now I can tell you I'm using paging on the 80x86, not
segments.  Most architectures support paging, but not segmentation. 
Besides, I took a good look at the 80x86 segmentation mechanism, and it
didn't look very useful.

> What does you basic IPC mechanism look like (message, sizes, mechanisms of
> transport, do they suppourt multiprocessing)?

I haven't implemented anything like that.  I have distributed computing in
mind, though.  Do you use registers, shared memory, networking..?  It
depends how much data there is and where it's going.  That's the kind of
stuff that should be handled by a high-level OS/language.

> How is shared video impliemnted?

You mean windows?  Well, each task has a video buffer (or several)
associated with it.  These buffers can be full-screen or windowed, text or
graphics.  (At least, that's the plan)

> How are device drivers implimented (accesed through call gates, shared
> code etc.)?

Both.. shared code and call gates.  Gates are only for calling supervisor
code from user mode programs, of course... I haven't done that yet.

> Does you taking model, memory management and IPC allow for
> multiprocessing?  What about distributed computing (what consitency, fault
> tolerant mechanisms have you used?)?

Yes, but I haven't gotten that far.  I need to set up a LAN or a simulated
distributed system, to experiment with.  The only fault-tolerance mechanism
I've worked out so far is redundancy.  I still have lots of research to do
in this area.

> What about the filesystem?  Is it tied to the device interface, is it
> "pluaggable" (ala linux VFAT)?

Oh, persistent storage... it treats all storage devices uniformly (although
optimizations for disks, etc, could be added).

The Persistent Store has close ties with objects and languages... actually,
it's the most important part of the OS... it manages damn near everything. 
Already, it does a lot of the work traditionally done by a language.

-- 
Tom Novelli <tcn@tunes.org>