Ker, win far20

[Michael David WINIKOFF]

> 
> 
> >> Hi everyone -- as promised my sketch for a simple kernel.
> >> feel free to flame, comment, criticise, compliment (:-) or suggest additions
> >> or changes.
> 
> I fear it's only going to be flames from me ;-( !

Fine. 

> 
>  AAARRRRGGGGHHHHH !!!!!!
>  This is *-disoriented unix-like stuff ! That should have nothing to do in
> a structured object-oriented OS !

Yes and no.
(1) I admit to to being influenced by Unix.
(2) I deliberately left out objects because
	(a) We haven't reached a consensus on objects
	(b) The kernel to me should be as simple as possible.

>  If that had to be like that, we wouldn't need anymore Moose Kerneling:
> we'd only have to use existing unix kernel (well, why not after all ?) !!!

Because most existing kernels are more complex and we can't extend them easily.

Actually this raises an interesting point -- what if we started with an existing
kernel (Eg. Linux, 386BSD) and added object support to the kernel?


> (if standard unix isn't satisfying, there are plenty of unix enhanced clones
> existing !)
> 
> - contextswitch():
>  it's up to the system, not objects (processes) to decide whether to switch
> context. In a massively parallel architecture, there may be no switch at all.
> Processes can have a "Wait" primitive, but contextswitching is a kernel
> problem.

As i mentioned this isn't really used by user processes.
You're right though -- it probly shoudln't be a system call then.

> 
> - self()
>  generically, objects may know of themselves; the self() call for processes
> should only be a particular instance of self() for any object.
> 
> - spawn()
>  cough cough cough !!! Warf !!!
>  Sorry, I just couldn't digest it !
>  "spawn" was a C add-up to make allow parallelism in an unstructured language
> (where thread-private data couldn't exist, everything being global !). It
> only allows auto-calling (very stupid). Such a horror shouldn't exist in
> the kernel.

Read the description -- the function takes an argument which is a pointer to 
code -- it is intended to essentially just add a task to the task table.

The code previous should 
(1) Allocate memory for the task
(2) Load the task's code into the memory

This is not at all like UNix'es "fork()" which I don't like.

> 
> - send(),receive(),poll()
>  ok for sending and receiving mechanisms; but again, why only for processes;
> any object may receive messages; or else, every object would have to be a
> process (why not then ?).
> But what would the mesg type be ? I hope that won't be only strings or
> (worse !) numbers ! Let's send/receive objects. Pattern matching will be
> done to separate objects.
> Polling can also be done by receiving in a sub-thread. (but having it standard
> is good). We may even make poll and receive atomic in some cases.

> 
> - alloc(), free().
>  No ! see what I said about memory management (also see farther)
> 
> - service(), ready()
>  Why particularize system services and have many varying syntaxes ?
> Let's have only objects. System objects which are the lowest-level objects
> will have the same access as other.
> 
> -  getdev(),setdev()

Ok then -- 
set_low_level_object_handler()

>  Why have devices ?
>  Devices are a new kind of object you bring about when you see your
> traditional OS concepts couldn't manage something (unix, thus dos: files
> can't manage anything, they're just data; devices are just read/write
> code).
>  In a OO OS, objects are what the system manages, and they are both
> data and code (I'd even like that we end differentiating each from the
> other), so we don't need to have a special concept as devices. What was
> called "devices" in previous messages was only low-level objects that
> would most probably be written in assembler or compiled from a low-level
> language (like C, for ex.). We'll have low-level objects as we'll have
> higher-level objects, in the object dictionaries.
> 
> 
> >> -------
> >> An initial "shell" could be a program that lets you make system calls ...
> >> This would be more like a system debugger/monitor ...
> Any interactive object is a "shell"; If we provide standard LLL, a LLL
> interpreter could be the first bootstrap shell.
> e
> >> -------
> [I won't talk about the implementation, as I can't agree with the kernel]
> 
> >> Memory allocation:
> >> 
> >> A simple way of managing memory is with a bitmap.
> >> If we have 1 bit = 1K byte then the amount of memory taken by the bitmap is
> >> 0.1% -- this is fine if we are managing physical memory.
> >> 
> >> alloc(size) 
> >> 	round size upto next kilobyte
> >> 	search bitmap for next free chunk of that size
> >> 	set the region to taken
> >> 	return pointer
> >> 
> >> free(ptr,size)
> >> 	reset bits in bitmape
> >> 
> >> Note: We can't compact physical memory without using virtual memory ...
> 
>  I don't agree at all with this either. See my previous messages about a
> multi-layer memory management, and a kernel that is/does but inter-object
> communication.
>  Also, optimal base memory block size depends mostly on the hardware (must
> be 4KB on the intel, 8KB on the SPARC, 256B on some 8 bit machines, etc).
> So let's have it implementation dependant.
> 
> >> ----------------------------------------------------------------------
> >> Michael Winikoff
> >> winikoff@cs.mu.oz.au
> >> Computer science honours. University of Melbourne, Australia.
> >> 
> 
> As I destroyed all that, I must show I can also construct. So I will
> soon post something (quick, then certainly full of errors) about how I
> envision things in an OO OS.
> 
> 
> 	   ,
> 	Fare
> Student (?) at the Ecole Normale Superieure, Paris
> 
> P.S.
> - my tabs can't hurt, as there's the same number of tabs at the
> two lines, and they begin the line; so I whatever size tabs are,
> it's ok. (but next time, I promise I won't put tabs)
> - beware of 80 columns non scrolling displays and multi-quoting !
> if you use more than, say, 70 columns in your texts, your quoted
> message won't display correctly/cleanly !
> 
> 

Quickly  (I have to go to a lecture now ...) we still have the problem of 
how to handle objects in an OS.

I deliberately left this out of this design which seems to have made it fatally
flawed and perhaps useless.

More later.
Bye for now.


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.