On Tue, 7 Jun 2005, John R. Hogerhuis wrote:
For the kind of thing I'm referring to is not usually very time
critical. The resolution is on the order of 15 to 30 minutes to an
hour... some stores get polled for data, the accounting system imports
the data and generates some reports which feed into other systems, etc.
Nothing particularly time critical.
Ok, so reading data from the guest may work in this situation, but you
need to be careful to avoid races.
Updates in the other direction is harder however, unless vvfat is changed
to emulate a floppy with floppy change notification and the guest has
support for changing floppy "at random".
Of course, if I understand what you are saying it doesn't have to tell
vvfat though... all events pass through QEMU so you have a place to hook
events and there's no polling involved. The more stupid the guest's file
structure, the more feasible such a solution becomes. "Open/create" and
"write" and "seek" should be possible to recover, efficiently even, if
you maintain a hash table or other data structure which lets you go from
block # to file (or block # to free space).
I guess the event you would be missing is "close," but a idle timeout is
probably a decent heuristic. Also if the file is locked, that would have
to be mimiced.
The concept of "file" does not exist at this level, only blocks of data on
a block device (hdd, floppy, cdrom etc, a long series of blocks to the
size of the device).
To make it look like files qemu has to make it look like a block device
with a block based filesystem on, and for write support the emulation must
support any kind of modifications to the block level filesystem the guest
may do.
There is several big issues involved in providing write support
a) On guest writes, the emulation must have a very good understanding of
how the guest writes to the emulated filesystem to allow it to piece
together the block level writes and map this to the files it is supposed
to represent on the host.
b) On host writes it must detect changes in the directory and reflect this
into the block level filesystem structure. You also have to battle with
filesystem and block level caches in the guest to make the guest see the
updated block level filesystem structure.
The only sane way of having a concept of files is to rely on the networked
filesystems (SMB/NFS/FTP/whatever), but this obviously requires
networking. Networked filesystem works on a file level.
Regards
Henrik
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel