Ker, win far20

[Francois-Rene Rideau]

>> 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 ;-( !

>> The kernel has the following system calls:
>> 
>> contextswitch()
>> pid = self()
>> pid = spawn(ptr to code, ptr to stack, initial pc)
>> kill(pid)

>> send(pid, message)
>> mesg = receive()
>> bool = poll()

>> ptr = alloc(size)
>> free(ptr, size)
>> 
>> reqid = service(devid, service_number, ptr to result/arg buffer, flags)
>> bool = ready(reqid)
>> 
>> getdev(devid, service_number, var pid, var code)
>> setdev(devid, service_number, pid, code)

 AAARRRRGGGGHHHHH !!!!!!
 This is *-disoriented unix-like stuff ! That should have nothing to do in
a structured object-oriented OS !
 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 ?) !!!
(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.

- 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.

- 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()
 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 !