We're have a determined feature set for the stable release. There are some features that should be implemented, but haven't well designed yet: - events (better services plug, polling, system events broadcast) - universal way to get sockets works To resolve this problems I'm offering my old design prototype - system bus.
Advantages: - it has a big part of code already (from first stage of development) - universal way to get the events - flexible and configurable events type - simple way to make single RPC calls *(1) - decrease load of filesystems and other services Disadvantages: - one more general service (this is not a disadvantage if system bus will be integrated to the nameservice) - performance lack in some cases *(2) This will solve the problem with sockets or with polling, task will do poll and will wait on the port/channel the event that will be signalled by the bus service. Each of service that need to have events will register own domain, each domain may has a many items (event element), for example local.root.fs.<id of fs that given by vfs>/vnode_id. Each event element will inherit the same permissions as the object assigned to element. Each event element may has several events slot, continuing our example: local.root.fs.<id of fs that given by vfs>/vnode_id:read_slot local.root.fs.<id of fs that given by vfs>/vnode_id:write_slot local.root.fs.<id of fs that given by vfs>/vnode_id:sys_slot I'm sure that the same may be done with RPC calls, I will write about other basics of system architecture later. But the general calls will be going directly to the fs or drivers (like it made now). Also, it will be better to make there calls in one universal API, then it can be adopted to POSIX calls. Now I want to discuss this. Your questions, comments - are welcome. NOTES: 1) single RPC calls means such calls that may be run without sessions (for example make a call to logger about service panic to make it broadcast) 2) for example - you are waiting changes on the directory - and this bus will add additional context switch i.e. fs makes pulse non-blocking message, thread of the system bus reply to the client. -- Alfeiks Kaänoken, Team Lead of the Jari OS R&D Team. http://jarios.org Free open-source microkernel-based multiservice RTOS _______________________________________________ Jarios-dev mailing list [email protected] http://lists.jarios.org/cgi-bin/mailman/listinfo/jarios-dev
