OSDev.org

well, at the very moment, i'm stuck on a design issue for Clicker ... one of the core services (accessing files from a ramdisk) is to be transformed into something going over multiple process (that is, the ramdisk is now owned by a dedicated process instead of being part of the 'micro'kernel space).

However, i'm facing a bunch of troubles such as:
- a new 'file descriptor' is to be allocated. This stuff is normally part of the caller's space only but how can it be allocated in client space from the server ?
- the server can prepare a list of pages for the mapped data, but only the client can locate available virtual addresses and map the stuff.

in other words, even if the server code is running in server space S, we need action to take place at three distinct place:
- Client space, before executing server stuff
- Server space
- Client space, after executing server stuff

i'm not very comfortable with the idea that all the remote servers will require three functions (and temporary data passed amongst them) for something that looked *that* simple at the first sight...

So i was somehow wondering if it could make sense to return "commands" with the reply 'message' such as
- get word 'N' from the 'message stream'
- allocate N bytes of local memory
- copy N-1 bytes from the 'message stream' in local memory
- get word 'M' from the message stream
- allocate 'M' pages of virtual space

etc.

... or maybe i should rather switch off all my electronic devices for the day and go build a snowman ...

the "virtual machine" would have "scratch" registers (probably stack-organized, as usual), the message stream (from which it can retrieve words or memory arrays), and likely a collection of "opcodes" that are actually requests for MMU/process services.

the advantage over plain code would be that even services running in user-level could issue their "post-execution" commands that can be handled by the kernel after the 'reply' message is received on the client side.

Depending on what the service is expected to do, some operations might however be refused ...

(gosh ... the more i write about it, the more it sounds like complete crap to my ears ... any suggestions ? i wish BI was there ...)

I do not fully understand, or I am unsure about alot of things you mentioned. The virtual machine, like a java virtual machine or something else?

kmcguire wrote: I do not fully understand, or I am unsure about alot of things you mentioned. The virtual machine, like a java virtual machine or something else?

well, like a very scaled-down java virtual machine, interpreting a dedicated set of opcodes (rather than JAVA bytecode), and seeing the IPC message as a primary resource.

Hi!

I'm afraid the reason why I don't seem to understand your approach (I understand it technically, yes, but not why you want to put it at this place...) is that I didn't get your requirements entirely.

Pype.Clicker wrote: However, i'm facing a bunch of troubles such as:
- a new 'file descriptor' is to be allocated. This stuff is normally part of the caller's space only but how can it be allocated in client space from the server ?
- the server can prepare a list of pages for the mapped data, but only the client can locate available virtual addresses and map the stuff.

Are these operations server-fs-specific? I mean, they are probably common to all filesystem-like ipc operations, aren't they? So why don't you design a common filesystem-interface and provide a client-side library which implements everything you need in the callers address space? You'd need 2 seperate messages anyway - one that contains information about the size of memory objects (to allocate buffers), and one to transfer them. If your biggest worry is really the number of messages, you could try it somehow like this:

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.....


About the vm: Maybe it's just the terms, but I wouldn't call this a vm then...it's rather a 'protocol' - a set of operations and rules to communicate something. I mean, it's going to be interpreted in the caller's space anyway, isn't it?

cheers Joe

Pype.Clicker wrote: However, i'm facing a bunch of troubles such as:
- a new 'file descriptor' is to be allocated. This stuff is normally part of the caller's space only but how can it be allocated in client space from the server ?
- the server can prepare a list of pages for the mapped data, but only the client can locate available virtual addresses and map the stuff.

For the first point, 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...?

For the second problem, I'm not sure there is any way around that in a microkernel. I'm not even sure why it's a big problem, but then again I don't know anything about Clicker's IPC mechanism...

I just want to say, and do not go getting off topic, but you guys in the forum make this forum the first place where I actually see someone write about a idea and it seems like a good idea. That could be because I don't completely understand it but for gods sake finally a forum where people know what they are doing.

What about this scenario:

- request: hello, i want to read _this_ file
- server: allocate memory, maps it to client address space, load datas, send responde

Pype.Clicker wrote: ... or maybe i should rather switch off all my electronic devices for the day and go build a snowman ...

Let it be for few days, one is not enough!

Hmmmm ... I'd give the client process a file descriptor or any kind of handle upon a kind of open_ressource call.

Afterwards, it's just passing the handle to the service along with the request and some data needed for working. That's just my simplicistic approach.

Very recently I've churned some Idea in my brain: If data amount is smaller than a page: do some copying. If it's >= a page: so some page array tricks and avoid copying hither 'n' tither. Just map a page array into the requestors address space and pass him the address: Here is the place where you find your data.

allocation of a file handle/file descriptor in client space: What about sending a reply with the handle to the client which is responsible for storing it at a safe place? The sensitive data is with the server so no client can do fishy things with it. (My opinion)

@kataklinger: quite a good Idea you present here: fetching data from a drive into a memory entity and passing it to the client with some mmap trick. That's what I've tought about too - for some four or five nights I reckon. It's time to speed up my little kernel a bit now that Networking is on its way.

There's no trick, just map client PD in server's address space. Maybe this is a little unsafe, I don't know. ::)

beyond infinity wrote: Very recently I've churned some Idea in my brain: If data amount is smaller than a page: do some copying. If it's >= a page: so some page array tricks and avoid copying hither 'n' tither. Just map a page array into the requestors address space and pass him the address: Here is the place where you find your data.

I 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. You could, however, (similar to what I stated above) pass the temporary memory entity as some kind of reference, and let the client decide upon a free virtual memory address to map it to. (Once again, this is how L4 messaging does it )

About mapping vs. copying: The idea is great, actually you could expand this to all ipc where larger amounts of data get passed. Whenever a memory region spans a whole page or more - just COW map it. Neither the sender nor the receiver need to know. This could really speed up things, at least for read-only data.

beyond infinity wrote: allocation of a file handle/file descriptor in client space: What about sending a reply with the handle to the client which is responsible for storing it at a safe place? The sensitive data is with the server so no client can do fishy things with it. (My opinion)

Seconding your opinion. Just make sure that the protocol is connection-oriented, otherwise you'll end up with a mess like NFS < 4 (IIRC), where any client could forge and imitate file handles which were opened by other clients...

cheers Joe

Client's address space isn't worry of server. Server should ask kernel (or memory manager) to provide some free address space of client, and then map physical memory which contains loaded data to it.

I think I've used wrong words, Lads.

The server orders an entity of virtual memory in the needed size.

Upon finish of action, it asks the kernel politely to unmap the entity. Then it sends a reply (action performed, Here is a handle to your data, yours sincerly, the server) with the handle to the vm entity so the client just maps it in and reads the data (or does what ever clients do with data)

Easier to grasp now? The client needs at least a handle to operate on so he knows what to tell the kernel if mapping the stuff into his address space.

stay safe

beyond infinity wrote: I think I've used wrong words, Lads.

I think so too...

beyond infinity wrote: The server orders an entity of virtual memory in the needed size.

Upon finish of action, it asks the kernel politely to unmap the entity. Then it sends a reply (action performed, Here is a handle to your data, yours sincerly, the server) with the handle to the vm entity so the client just maps it in and reads the data (or does what ever clients do with data)

Easier to grasp now? The client needs at least a handle to operate on so he knows what to tell the kernel if mapping the stuff into his address space.

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..... ;D

cheers Joe

Oh, believe me, my kernel reacts nicely. I've got stable memory entitry handling, so no worries with that. I've just to get my @$$ in the hands and do something in that reagards finally instead of code churning for the tcp/ip stack.