Reply to Fare' -- LONG

[Michael David WINIKOFF]

> 
> >> > Giving device drivers their own priority -- good.
> >> >
> Ok, but WHO (what processes) can set up device drivers ?
> if anyone can call its own local driver, there's no more security. See (1)

THis comes back to security -- any comments/suggestions?
THe concept of a superuser is a relatively simple (if rather insecure) way
of doing things.
Of course we'll have to introduce the notion of process ownership ...


Alternatively we can decide that this is a single user system so anyone logged 
in from the console is "safe" ...

> I know - tell me more if you know others). That's why the system should offer
> many different capabilities of allocating memory, from raw reservation of
> contiguous physical memory (to device drives) to garbage collecting-aware

NO! The kernel should offer a single simple and (hopefully) sufficiently 
general method that is used by all.
Why? It is not possible to anticipate the needs of all languages so we should 
make the system "extensible" in some way -- given that this is done it is
a waste to stuff some of the language specific memory allocation into the
kernel.


[Stuff about us copying Unix and how bad MS-DOS and MacOS are deleted ...]

(1) There's no need to go around insulting DOS and Mac -- we all know DOS's
shortcomings and the Mac was a good idea at the time.
(besides -- I do now some computer scientists that love Macs)

(2) The reason why Unix is so popular is that the original (small) Unixes 
had a number of good ideas (that tend to be taken for granted these days)
[Eg. device independant I/O]
Unix DOES have weak areas -- I see nothing wrong though in copying Unix's strong
areas.

> There we come to an important point: error handling. Of course, old OSes
> (stands for Old Shit ?), being based upon C, couldn't integrate this concept,
> neither could they understand anything sensible about HL programming (nor
> LL programming with respect (?) to DOS - Double Old Shit (OS/2 being half-old
> shit). Recent language like ADA, later version of (true) C++ and CAML do
> include exception handling, and many HLL I don't know certainly do. I like
> very much that of CAML (not knowing the others - tell me - 't'should be
> mostly taken from the same language as for C++, but CAML should be better
> because of automatic genericity as opposed to C++'s template hack). The
> Kernel should include exception handling as a standard, so that objects
> can exchange not only usual data, but also exceptional data (notice that
> these language do not allow embedding exception in data itself by declaration
> of exceptional format as should accept the language I vouch for (of course,
> their are ways to obtain equivalent results, but then why not repeat we all
> use Turing Machine equivalent languages ?)

Were designing an OS - not a langueg.
I'll come back to this point again, I think you're trying to throw a lot
of what properly belongs in a language into the kernel -- thereby imposing
a uniform object oriented view on all users of the OS.

Personally I will disassociate myself from MOOSE if we decide to enforce
OO programming on everything ... I feel that OO is overhyped.

Personally I'd much rather use a Very-High-Level-Language like Haskell --
OOPLs are based around imperative languages and are lower level as a result.

> 
> (BTW, who do have read my HL specs, and what do you think of it ? Do flame
> its flaws, you're welcome, but do encourage what pleases you in it too.
> Do not hesitate to ask for more precisions)
> (NB: CAML is a particular version of ML integrating imperative programming
> as well as declarative one; we work with it at the School (Ecole Normale
> Superieure) in its CAML light 0.5 implementation by Xavier Leroy & Damien
> Doligez; it's available for example at ftp: nuri.inria.fr - neither place
> nor time to tell more about it here; unhappily, the syntax being to concise
> it very dirty, as opposed to lisp's lots of insipid and stubborn parentheses).

I've used SML for a moderately large project ... my personal opinions:
(1) SML's syntax is *HORRIBLE* -- it's got all the rebundancy of Pascal ...
Haskell's or Miranda's syntax is HEAPS nicer.
(2) Exceptions should be reserved for programming in the Large and possibly 
removed -- trying to isolate an exception is a major pain.
(3) Ditto for side effects -- one of the bugs that I had to isolate involved
a function that modified it's argument being called without first making a copy
of the argument

Objects:
> >> > I like the approach of simply defining a standard format.
> Well, if not, this would no more really be OO'ed, and be another DOS, waiting
> to be (VERY quickly) obsolete !
> OO standardness is compulsory. To be in advance with other existing OS
> projects, we must also include NOW genericity (for the which C++ templates
> are only a hack) and logical programming (the most common use is find how
> to find the "best" path to transform a virtual object into another, knowing
> the elementary virtual transformations available and their physical cost).

Yet another OO fanatic ... :-)
I repeat -- objects are not magic ...

> >> > 
> >> > Why the "@" in semaphore@Down ?

Sorry -- I forgot to add ":-)"

> 
> >> > Should we have spinlocks too?
> On multiprocessor systems, of course, but that's a kernel implementation
> concern; let's not mix specs and its impl' again !

Yes -- however if we neglect them then the kernel on a multiprocessor will 
have a different interface to the kernel on a monoprocessor.
I suppose this would b einevitable anyway though .. :-(

> How complicated !
> Again, let's program it by layer. The lowest (kernel) layer does a Andreas
> says. Then, you can have a filter monopolize the lower-level resource to emit
> events on a queue, then if you want, mix that queue into a general event queue
> for stubborn processes to un-multiplex the global queue, as stupid current
> systems do. YES, you CAN do it ! But once you see there are simpler, easier
> means to handle data, by piping data just where you want, you WON'T use the
> centralizing algorithm. Everything is easier, neater, quicker, better, when
> objects just fit one into the other.

Think of it as a server object for timed events.
BTW I/O events have nothing to do with this -- the kernel could easily send
them directly to the correct address when they are generated.
I feel however that this addressing should be centralised rather then be 
scattered among the various device drivers
(1) It means less repeated work in the device drivers
(2) It's simpler to keep track of and maintain.

> Of course again there are several layers ! Every program uses just the
> one it pleases. Every layer has a standard interface; every interface can
> be filtered for programs not to interfere each with the other.

The existance of multiple layers hasn;t been mentioned yet.
I don't consider this obvious or even desirablefor efficiency reasons.
Each layer of indirection multipllies by the inefficiency of the previous layers

> Well, there's a difference between supporting a language and have it as a
> primary language. ANY system can run ANY language as long as it's powerful
> enough. You CAN run AppleSoft BASIC on a Unix WorkStation; but you just WON'T,
> because it's without any interest but historical. That should be the same for
> MOOSE and C/C++: of course you can still use C, but you won't be able to
> -directly- use all its power with such a LL dirty language, and you will have
> to include many a library to interface both. Moreover, standard LLLing allows
> easy implementation of ANY language you want, by providing a fore part of a
> compiler from the new language to any (combination of) existing standard layer
> of THE PL.

And there's a difference between supporting (allowing to conveniantly interface
to OS services) and being able to run by writing our own abstract kernel 
interface ...

> MOOSE should be Pee O aRe Tee A Bee eL Ee. However, we all come to have 386
> PC's, because cloning has made these stupid computers CHEAP and STANDARD.
> But, we'd love  to be able to run our new standard OS on an even CHEAPER,
> NON-STANDARD, BETTER computer (like, say, the Amiga or RISC machines).

I hate to say this but the AMiga isn't better -- the A600 and A1200 are based
around antique processors (68000 and 68020 respectively) and don't have anMMU.
Note that to the best of my knowledge NONE of the AMigas have MMUs.

The good thing about Amigas is the operating system 
 
> >> > Persistent objects subsume both processes and files.
> >> > Getting rid of the concept of the files is (IMHO) a strong forward step.
> see what I said above about Unix, files, and objects.
> 
> >> > One idea which may simplify swapping is to use a single address space across
> >> > all objects -- possibly even the one corresponding to where they are stored
> >> > on disk.
> >> > Of course most of the address space will be inaccessible ...
> >> > 
> >> > The main advantage of this scheme is that it makes shared memory simpler to 
> >> > program with -- otherwise pointers have to be avoided since the addresses
> >> > will differ from process to process.
> >> > 
> >> > [But see arenas later]
> Again, that's for implementation eyes only. See (1b)

Nope -- it affects the semantics of shared memory that will be visible to 
appplications.

> >> > (8) Microkernel:
> >> > 	Seems to be the way we're heading. Good.
> 't'should be able to run even on my HP28 ! Of course, you won't have any
> tools, then, hardly a few devices for the simplest I/O.

No -- Microkernel doesn't refer to the final system size.
It refers to the system architecture.
A microkernel design simply means that the kernel provides a minimal set
of services (Eg. memory management, multitasking and IPC) and other
system services (EG. file systems) are implemented outside of the kernel.

> Hey, this has few to do with an OS specs: Very Unportable ! Let's leave this to
> LLL implementation(s): sure it can be used, but we don't use assembler hacks
> -only- for the fun of it, but also to find HL requirements. What do 680x0
> programmers would say if they heard you with these 386 tricks ?
> There's only one thing at HL: you may want to allocate an object, and you may
> want to publish it, so that others can see it where you put signs.

Caught out on this one -- I have never programmed a 386 and i have programmed
a 68000 -- I guess that makes me a 680x0 programmer :-)


A problem that has to be handled when using shared memory is that pointers 
into the shared memory region are not normally valid across processes and 
hence one cannot store data structures in the shared memory region that use
pointers -- this differs significantly from the semantics of normal memory.

My suggestion ensures that shared memory has (in this respect) the same 
semantics as normal memory.

> >> > (13) Should we be providing threads? (I don't think so but am open to debate)
> what are threads/tasks but little/large objects ? Why build such a distinction

Threads share data space whereas tasks/processes don't.
Tasks are objects.
Threads would correspond to concurrent method activation within an object.
SInce the data is shared between the threads locking becomes important.

> * about DOS FAT systems:
> Some talk about reading/writing it. Of course, this is obvious on 386 based
> computers. But DOS FAT is so @#$^#$%^& that no sensible people would willingly
> use an OS with it as a main FS. Whatever FS is choosen to work on, this should
> be included as a device driver, not in the Kernel.

For the moment DOS compatibility is a definite plus.

> 
> 
> * Could one explain a poor ignorant frenchman the joke about Moose ?
> ('heard you talk about a Mr Moose; who was it ? )

Some american cartoon ... :-)

> 
> * dmarer:
>  Keep the Kernel as pure as possible: OK.
>  Allow non-OO programming: ??
>  - if it means device drivers are not bound to be OO clean, and heavy
>  computation need not look multiple method tables at each iteration, ok;
>  but if it means there is not a standard compulsory class hierarchy
>  from low level raw data classes to high level virtual classes for system
>  calls, I don't agree anymore !

Again -- you're forcing any users of the system to use an OO language.
I don't like that.
If you want an OO only environment, I suggest you get hold of something like
Smalltalk, Actors or Self -- all of which are pure OO languages which provide
an OO based environment.

> 
>   That's a general method for protection, which is after all only a "view" of
> sharing objects. To enhance this, you may add a key to names so an aggressive
> program not be able to pirat you because you use common names.

That's what capabilities are.


>  In fact, I think the Kernel Set should be exactly the C/ASM coded methods for
> handling low-level objects: tasks/thread/procedures (executable code in
> general, including stack management, and exception handling), memory
> allocation, object typing, virtual pointers and naming (including subnaming
> and polymorphism, linking and unlinking object to the running system (imagine
> the coding/decoding needed to load/save an object from the running session
> from/to mass memory). Nothing more.

Nothing MORE?!
I do not think that object typing, polymorphism etc. belong in the kernel.
Object typing should be done at compile time.
If you want an interprative system that can be written but you shouldn't
FORCE the system to do interpratation.


To summarise my comments:

The main problem is that you are confusing language and OS issues.

An OO operating system does NOT mean (IMHO) that all the support for OO 
langauges should be built into the OS (and certainly not into the kernel)

To me it means that the OS should provide some operations that make it easy
to implement persistant objects.

-------

* You should allow the freedom to do things at compile time for efficiency
reasons.

* You should allow the use of non OO languages -- otherwise you don't have a
generic OS -- you have an OO programming environment.

------

* The kernel should be minimal. It WILL have a resemblence to Unix in some areas
simply because in some areas Unix has done things in a good way.

Note that objects come ABOVE the kernel.

You don't want to have the kernel enforce complex semantical policies.
By lifting up such things into the compiiers you gain in efficiency and more 
importantly in maintainability.


Requiring the kernel to do polymorphic type checking and inheritance is like
requiring an OS to run structured code ... 

Michael
winikoff@cs.mu.oz.au