Kernel 0.1, Win

[Gary D. Duzan]

In Message <9303212331.9646@mulga.cs.mu.OZ.AU> ,
   Michael David WINIKOFF <winikoff@mulga.cs.mu.oz.au> wrote:

=>>    Types are a sticky issue. They are basically language-specific, and
=>> we are building a system that needs to work across languages. I don't
=>> think we can expect to teach the kernel about every data type that
=>> comes along, so I think that any type checking would have to be done
=>> at one or both ends of the communication rather than in the kernel.
=>
=>Yes.
=>Do you have any suggestions on the mechanism for doing this?

   Well, the most efficient would be to ignore types altogether and
assume that both ends know what they are doing. We could also define
some standard types (8/16/32/64-bit signed/unsigned integer, floating
point, fixed length string, variable length string, etc.) and require
that all IPC use these types. We could also provide libraries for
each language to convert language types into system types. Expanding
the libraries would allow for more system types. I don't know if
this is a good idea, but it is an idea.

=>> think that a persistent object system on an MMU-less system would be
=>> much fun to work with. I would assume that such a system would need to
=>> stop and checkpoint objects fairly regularly, which would be rather
=>> ugly from the user's point of view.
=>
=>THis is all hypothetical BTW, but, I'd imagine that checkpointing objects wou
ld
=>be done manually.
=>The user would be aware that any objects not saved before a system crash woul
d
=>be lost.

   I would have thought that persistent objects were meant to hide
the persistence from the user. I suppose we could do a transactional
system (logs & checkpoints) to deal with crashes, but that would be
quite a chore.

=>> [ stuff about communication semantics ]
=>>
=>I think providing all three  at the user level is what we should do.
=>WHich get done at the kernel and which get done by libraries I'll leave
=>o experts in the area (like yourself) to decide.

   However, the system will be more coherent if we encourage a
particular communication mechanism.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts