Marc E. Fiuczynski wrote:
>> Now back to your question 2) again. Yes, it goes back directly from
>> Windows to Linux *after* the windows system call. But the system call
>> need some longer time. For sample ZwReadFile() blocks the Linux, until
>> it is ready to gets data from file (blocked read).
>
> That's terrible!!! Is there no way to make asynchronous read/write requests
> inside Windows? Or is cobd expecting sync responses to the disk block
> read/write requests?
This is a design problem in coLinux.
Generaly coLinux stops linux VM while a block transfer is in work. This
is very nice, because linux should not remap (or swap out) a memory i
this time. The windows host function write directly into the linux
mapped memory. The data area for block device operation is shared
memory between coLinux and Windows. It is temporaly shared, only in the
time, the block read funtion is in work.
Let me first tell you the current implementation, on a sample how
coLinux reads a single sector from a cobd.
- Linux VFS calls fops struct to read a block.
- Destination for data is a virtual linux kernel memory.
- Switch to windows host. We are in linux.sys now.
- The "read" function for this, calls a wrapper
'co_monitor_host_linuxvm_transfer' with function pointer to read from
host filesystem.
- 'co_monitor_host_linuxvm_transfer'
maps the data memory into host virtual memory,
calls the 'function pointer' and
release the memory from host.
- Then goes back to Linux OS.
- Tells Linux VFS, that the memory are filled with data (ok request).
The problem is, that 'co_monitor_host_linuxvm_transfer' is an allround
mapper for all calls (read/write on cobd/cofs). On enter, this funtion
maps the linux memory to host OS memory, then some windows functions can
call. Before exits, this function unmaps memory from host OS. We can
not let a background call access to data memory outside of the funtion
'co_monitor_host_linuxvm_transfer'. That was the base implementation.
For an async access, this is not good. The memory must be mapped until
the procedure is in work. The memory can only unmap after the APC call
from windows give the feedback.
One of my idea is, to split the 'co_monitor_host_linuxvm_transfer' into
a function, that not unmaps the memory on exit. The APC function should
write the return code into the memory and then unmap it. Now, I have an
other problem: What is, when we never gets an APC call? Who will free
and unmap the memory on errors?
The main problem is the Function ZwReadFile and 3th/4th arguments
(ApcRoutine, ApcContext). I can not find informations when windows
called this ApcRoutine. It is called every call of ZwReadFile? Is it
called only on error free read?
Where I get the counter of a partial read? For sample, if I read 1024,
but from current file position to the end of file only exist 512 bytes.
Other problem: If an partial read give only some bytes from a bigger
request, would the APC function call again, if the rest of bytes are
available later? Or must I call the read again?
Have started some coding. Sources are only for case study!
http://www.henrynestler.com/colinux/source/devel-async/
All linux side callers for cobd-read/write are splitted for async mode.
All old calls and for cofs are changed to get it in old sync mode.
Open flags have changed, removed the adding of "SYNCHRONIZE" and
"FILE_SYNCHRONOUS_IO_NONALERT" on default open.
The block read request goes from linux to host OS and starts the
ZwReadFile/ZwWriteFile, then host OS dies.
The return from host OS to linux and the APC caller is not right
programmed. I'm missing some information, how to handle it.
It is not runable. It will cashing your PC every time you enable
'setcobd=async' as bootparams.
If not set 'setcobd=async', than all calls work in old mode and the PC
is not crashing. This give me the good feedback, that changing for old
mode are ok.
In my patch the function 'co_os_file_block_async_read_write' prepars
all params for the 'ZwReadFile' in function 'transfer_file_block'. The
APC function 'transfer_file_block_callback' should give back the status
request to linux back.
DrPizza, you have ideas again, or working sample source? A single small
example with a reading from a file with enabled APC call would help.
The best would be a "dummy.sys" that reads a file and prints some about
to a debug view. This dummy driver need no other function implements.
The driver should read the file on start. If this driver working, I can
move such functions into linux.sys.
Currently I have to many questions about functionaly of APC for calling
'ZwReadFile'. In german we say, "this blind programming" would never run.
--
Henry Nestler
|