Ker, win

[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 feel that this way of doing things locks out the object from the kernel, and
> as Fare' said, becomes a "standard unix kernel" type of kernel.
> As mentioned hundereds of times i previous mails, we need to define what we
> want to achive, but because of me getting very exhited (the adrenalin is
> pumping up the veins :-) I'll give you my suggestion later.

In retrospect I shouldn't have posted -- I should have waited till we had
a consensus on objects or proposed an object based design.

I think it is fair to say that objects (whatever that means) will play a role
in the design of the kernel.

> 
> > The kernel has the following system calls:
> >
> > contextswitch()
> > pid = self()
> > pid = spawn(ptr to code, ptr to stack, initial pc)
> > kill(pid)
> 
> This contradicts my way of looking upon the problem.
> As I see it:
> There are two type of contextsswitches that we must have.
> Both the preemptive and the event-based.
> These are contradictionary (?) in them self in a way.
> But the important things.
> An application must be able to act on an event imidiatly when it is raised.
> The kernel should make it's contextswitches whenever the "heart beats" (clock
> ticks).
> This prevents us from makeing a simple round robin implementation!
> We must have tasks that have more prioriaty than others, eg. the tasks used
> by the user should have, say, twice as much processing time as opposed to the
> others, that are latent from the users actions.
> I.e. no input, no need to give the task his full share of time.
> Much user input - more time given to that task than given to the others.

Note: I suggested round robin and the other implementation as the simplest
possible. 
Not neccessarily as a good or practicle way of doing things.

If you're machine is sufficiently fast then round robin should be workable.

> 
> Now back to my fundamental idea (don't know if you like it or not because of
> lacking response (well, not you Fare')) where the device has its own list
> of tasks/threads that might want to have input from it. Whenever the device
> gets an event (key pressed on keyboard) the running task is interupted.
> The interupt routine passes the message further to the thread that wants it.
> The thread processes the message until no more time left, and the kernel

I don't like this -- I prefer to simply have the interrupt handler create 
a message that is placed in the appropriate place but do not context switch.

Under MULTICS (?) this was done --- a user could get more CPU time by hitting
a key every now and again ...

> contextswitch to the task that was running before the event.
> I realize that this could make a large overhead and that tasks could nest them
> self to infinity (interrupt on interrupt on interrupt...).
> The way to go round this is to have each task maintain a que that will be
> handeled when it gets its timeslice.
> This will turn my previous idea on its head in a way, but the basic concept
> will still work.
> Of course most of this should be put into the task-device.
> 
> > send(pid, message)
> > mesg = receive()
> > bool = poll()
> 
> No one will never poll or ask for a message, or send one if everyting is
> developed as devices.
> We can have a send device that will act the same way as a keyboard device.

These kernel calls will be used in the writting of the devices.

> 
> > ptr = alloc(size)
> > free(ptr, size)
> 
> I support these things for the kernel. A very simple basic memory allocation
> scheme with MemoryAllocate, MemoryReAllocate and MemoryFree as proposed by
> Dennis in rev. 0.
> All GC, word alignment etc. will be handeled by a device.
> Keep the kernel clean and simple.

Good! (Of course I agree - I suggested it :-)
> 
> > reqid = service(devid, service_number, ptr to result/arg buffer, flags)
> > bool = ready(reqid)
> 
> Preferr the Amiga way with sniff/tiff/gif/etc. devices/objects that are
> published through a dictionary.
> 
> > getdev(devid, service_number, var pid, var code)
> > setdev(devid, service_number, pid, code)
> 
> You should be able to insert a device into the dictionary as long as there
> are no device already occupying its postition.
> 
> Have to run
> to be continued...
> 
> Arff
> sig.'s in for 1000 miles service
>         --Andreas Arff          andreasa@dhhalden.no--
> 
> 


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