[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Looking for an easy way to exchange data bidirectional

From: Johannes Schindelin
Subject: Re: [Qemu-devel] Looking for an easy way to exchange data bidirectional between host and guest (including some suggestion)
Date: Wed, 8 Jun 2005 13:22:52 +0200 (CEST)


On Wed, 8 Jun 2005, Henrik Nordstrom wrote:

> On Tue, 7 Jun 2005, John R. Hogerhuis wrote:
> 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".

The support infrastructure is already there. But there is not yet any way
to set it (ideally it should auto-detect if the emulated device is a
floppy or a hard disk). It is also not tested.

Every half-sane PC OS has support for changing the floppy "at random", as
every PC floppy device has a button which the user can (and will) push at
the worst moment.

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

No. It MUST NOT have a ver good understanding of the guest writes, because
different OSes have different write strategies. The block driver MUST be
agnostic to this. That is what makes write-support so hard.

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

That is the main problem. Basically, in FAT a file gets written in three
stages: the directory entry is modified, the block list (in the File
Allocation Table) is adapted, and the actual data is written into the
blocks. Now, a seemingly good heuristic would find in which order these
entries are written, right? Wrong: The caching more often than not makes
this infeasible. While the OS really writes the three stages in the same
order, it does so only to the cache. And which cached blocks get written
out first is quite deliberate. Linux uses (very limited) caching on
floppies, too.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]