OSDev.org

thanks for your feedbacks, dudes. i'll read all this a bit later ... was indeed busy building snowman (well, sort of. without snow) this week-end.

Besides, Pype: it is the services responsibility to tell: is this operation for me? It could even ask some user manager service: is that process/thread entitled to this operation?

Basically, you've got a big choose_case(expr) in your services main function, which filters out: available operation/not available one.

Then the operation function itself can perform further tests. I wouldna bother the kernel with stuff like: is this operation for service X?

The service althou could export a list to some space where all available operations(and for whom) can be viewed/altered, but in the beginning I wouldna advocate for such overhead.

I honestly don't really understand your plans about "virtual registers" for IPC: How do you envision this. Is there some graphical sketch we could excange args over?

The thing about: give me n bytes from the message stream (which I am entitled to read from/write to) I consider pretty fine.

I just don't see a necessity for a kind of virtual machine at that low level. Maybe we could elaborate on this later on,but take into consideration that I'm about to go to south africa for about two weeks, and then back to university for studying --- let's see what's going, eh?

Hope I don't confuse stuff.

stay safe

OK, we were talking about quite the same thing then. Just make sure you have a really _nice_ kernel, so that it reacts when you politely ask it to unmap the region.....

Make your kernel to be nice and he will be nice. It's your kernel so code it to do what you need, for instance unmaping regions.
Server doesn't need to know anything about client's address space, it just asks kernel to map X pages from his address space to client's. Server only needs to know beginning of the memory region, so it can send resopnd to client: "you have xxx byte of data, here is start of your data".

I just don't see a necessity for a kind of virtual machine at that low level. Maybe we could elaborate on this later on,but take into consideration that I'm about to go to south africa for about two weeks, and then back to university for studying --- let's see what's going, eh?

Well, I would like to visit north Africa, and enjoy the Paris-Dakar Rally

think this is exactly where the problem lies: The server shouldn't be responsible for the client's virtual memory layout, therefore it can't just find a free address and map the data there.

Precisely. that's somehow what DataStreams were supposed to solve: rather than saying "find me some virtual addresses area in client process for me to map ...", the server 'sends' the physical pages (via microkernel call) over the data stream and the client (still via microkernel call) maps those pages in the 'reading window' of its own end of the datastream.

QNX has a solution -- make file descriptors equivalent to IPC channels. When a client "opens a file descriptor", under the hood it is really establishing a connection with the file system server. Does this help...?

Hmm, seems i indeed overcomplicated the whole thing, indeed. I guess it makes sense to have kernel-level code invoked at client side that will create the 'system resource slot' first (that's the closest entity from a file descriptor in Clicker) and _then_ contact the remote server.

Transfer the memory objects as 'references' (the ipc subsystem in the kernel needs to support this then), then the receiver reads these objects' properties (the size, for ex.), allocates buffers, and then tells the kernel to copy them into its own address space, with no need to notify the sender by sending another message. This was just an idea that I wanted to provide in my system. Don't know if it fits in your stream-based-ipc though...

will have to take time to think back at this.

Thanks all for helping to 'KISS' it ... i guess the hack-ish file server & interface that involved the problem will just be fixed with a hack (e.g. upon attempt to access the 'SFS-boot-ramdisk' service, the system will check the ramdisk can be mapped in the current process and map it -readonly- before it proceeds with good old code).

Cleaner solution and cleaner interface will be designed for the 'real' filesystem that's yet to come.

Story is even more complicated if kernel (or whoever) swaps pages to disk.