-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05.01.2015 12:38, ba_f wrote:
Hello L4-Hackers,
i noticed some wiered behavior when using l4io_request_iomem().
Have a look at this simplified code:
Server::dispatch(l4_umword_t, L4::Ipc::Iostream &ios){
ios >> v1; ios >> v2;
l4io_request_iomem(ADDR, 4, L4IO_MEM_NONCACHED, &baseaddr);
ios >> v3; ios >> v4;
}
When using l4io_request_iomem(), it kind of destroys the ioStream so that v3 and v4 get wrong values. v1 and v2 are correct and of course, i checked that v3 and v4 are correct when l4io_request_iomem() is not there.
It's ok for me, since i just rearrange my code.
But how does this behavior come? is it a bug, maybe?
This is intentional behavior and caused by the way clients and servers work.
L4 IPC basically works by the sender putting data into its UTCB and then invoking a system call. The kernel then copies the data from the sender's UTCB into the receiver's UTCB and wakes up the receiver if necessary.
When your server's dispatch() method is called, the arguments for the call are still within the server's UTCB area. The Iostream's stream operators allow you to retrieve these arguments and deal with them.
In your code you now do an l4io request, which in turn sends an IPC message to the IO server. As explained above, for that purpose your server will now put data into its UTCB and issue an IPC system call. This overwrites any data that was previously stored in the UTCB and hence invalidates the Iostream's content.
Possible solutions: * Move the l4io request to the point where you have read all data from the server request, i.e., after the "ios >> v4" line. * Alternatively, copy the whole UTCB content to an intermediate location before issuing another IPC.
Hth, Bjoern