OSDev.org

http://prdownloads.sourceforge.net/clic ... z?download
http://prdownloads.sourceforge.net/clic ... z?download

Here you get it the whole kernel now uses CodeMonkey tool for fancy linkage and a new message passing replaces the obsolete events processing engine

started writing a "userguide" in my wiki: http://clicker.sourceforge.net/wiclicke ... stioModule
http://clicker.sourceforge.net/wiclicke ... anelShower

works fine in QEMU.

Does the test-process display some spinning character on console1?

apart from that - I get used to the handling of your baby. )

only if you also load "semdemo", afaik.

works in bochs, qemu.

needs a user guide and some usermode programs, particularly a shell and games.

You're welcome

Seriously, i know people like to see a shell and a tetris when they bootstrap a hobby OS, but they weren't top-ranked in my priority list. I'm still looking for a good VM86 stuff for enabling video mode (don't expect a shell before there is a way to put it in a separate window)
I'm still needing a decent keyboard driver (i mean, with plugable keymap ) but that was plain silly to start coding it before we have the message passing to deliver keys to the program that required them, don't you think ?

As for the shell, I'm developing a shell together with somebody from my school (two actually), intended to be mostly OS independent. Called ncsh on sourceforge, should be reasonably easy to port. Not full-featured, and since we removed readline no automatic line completion but it should suffice for most beginning OSes until they can support (and want to ...) bash or alike.

The debug and show-funky-things-panels of clicker are quite nice stuff. *g*

and I've had the semdemo stuff loaded too, so that explains the spinning characters. There are a buncha threads spawned off too, if I remember correctly.

*btw .. thinking* The vm86 stuff is tricky. It needs quite some time to implment the additional infrastructure - properly, not anyhow. *gg*

Just keep up the good work. Cool to see some micro kernels around here

;D ;D ;D

I got messages exchanged between user processes. And it only took me 1 day to patch existing "scalltest" with it ...

really love that new ports-and-messages stuff

That deserves 0.9.0

;D ;D ;D

http://prdownloads.sourceforge.net/clic ... z?download

done. See instructions at http://sourceforge.net/project/shownote ... _id=300338

cool stuff )

I like it. It advances more and more. )

btw: how are you doing it: you assign a port a name and the other process wanting to use the port just needs to get the name - either via command line argument (fork/execve) - and retrieves the actual port number with a lookup system call? say "openport("gui_port");"? which returns the port number, which you use to "dispatch(port_nr,&message);"?

Are the ports connected to processes(allocated in the tcb) or stand alone so that each process can attach to any public port or probe any public port for messages? Or two processes can share one private port? (me starts to be unhappy with the current events solution - it is simply unneccessary overhead to redirect flow of control to an eventhandler if a wakeup does the same thing ... *grmpf* I've just thought it might be handy for async events where you have the possibility to register a handler --- you load a file and stroll off to do something else until the server triggers the event ... head in the clouds, that is)

What is planned:
- the parent will automatically have a "default port" which the child can retrieve with a method on the "process" resource (eg Process::GetParentDefaultPort())
- the execution environment can indeed allow process to give names to ports and resolve port ID from a name.

What is hacked at the moment:
- both parent and process use a kernel-scoped variable which keeps the ID of the port created by the parent and requested by the child

send() and recv() messages are then using the port ID.


Ports are kept appart from TCBs, but when a thread creates a new port (eg. allocates a port ID), it becomes the "owner" of that port. There's no such thing like a "public port" so far. It could be added but only in the sense "a process gets owner of the public port, use it for message reception and then make it public again". Having multiple readers on one port is not part of the design.



i had the same problem with my event system. It just proved to be overly complicated and useless ... Finally the idea for asynchronous signals will be a single "exception handler point" where the kernel can send the user process: additionnal info about why the user process has been teleported here will then be available ... in a port

tested on bochs --> OK
tested on qemu --> OK
tested on real machine --> OK

but, i dont totally agree with you about the shell, IMHO : it can be useful to debug and test what your OS is able to do... i'm very simple shell (that can be removed at any time) call new added functions, or to debug problems and i don't think that this is a bad idea

BTW : where is the new code that handles message passing in Clicker ?

kernel/mtask/ports.c

It's used in mods/io/basics, mods/tests/testio, mods/io/ata, mods/tests/syscall...



indeed. My approach is then to write a module for testing the feature and have it loaded using the module loader. If the thing to be tested is a bit more complex, i'll use a new pannel like for "testio" etc. It allows to keep test code appart from core code and avoid the needs for maintaining the list of "built-in" stuff.

Now, i admit, it would be better with a "help viewer" module aswell...