[Jari-developers] Some notes about architecture,

[Alfeiks Kaänoken]

So, 
I need to make some notes about structure.
The first ikernel didn't know something about non-local resources such as 
memory or cpu, 
ikernel don't participate any proccesses with load balancing within the nodes.
Ikernel provide only local resources basics (mem, cpu, abstraction layer for 
the server level device drivers). In this case I will exclude vfs from ikernel 
and all other fses like a portfs/cpufs/memfs etc ... there are will be on the 
server level and servers will uses JP protocol for intercommunicating with the 
ikernel by the ipc_port (look out ikernel/include/ipc/port.h). Actually, 
ipc_port is the memory object in the ikernel memory space that controls 
transmission on the local node layer, ie for transmitting JP frames between 
server and ikernel following with the system call and shared memory, it's 
declarate to use three levels (ikernel/server level/user level).
All parts of the ikernel and servers set must be intercommunicate via the JP 
protocol& is a good abstraction, yes it will be slower but it's better than 
things like RPC and others.
Ideally in the future the user or developer will not care about fs location, or 
device location etc ... and no nfs, we're just send a request and get the data, 
we're just do the exec() call to the vfs and get running process on the pointed 
cpu via cpufs.
By this scheme must be works a loadbalancing server or application.

Generally, I want to told that we're don't include all from all to the ikernel 
to the low level part, ikernel is a microkernel-like subsystem, that present to 
the upper level just abstraction, just boot up and getting working. Without 
this we're can get a second trash calling linux or an old unix with some new 
implementation.
In this case the first targets is not a get running ikernel with support of the 
fs, without ports, protocol and implemented support for everything to run some 
ELF binary.
It's better to take a longer time for development and get run Jari with the 
normal architecture, instead of the slippy code writing.

thanks.

-- 
Alfeiks Kaänoken,
Technical Team Leader of the
Jari R&D Team.
http://www.nongnu.org/jari/
Get the innovations!