RE: [Qemu-devel] Patch: virtual vfat support

RE: [Qemu-devel] Patch: virtual vfat support

[Andreas Bollhalder]

Hello

I tested the QEMU.EXE from FreeOSZoo with your patch on WinXP.
Starting QEMU.EXE like the following:

D:\TEST\QEMU\qemu.exe -L . -localtime -m 32 -isa -cirrusvga -user-net
-enable-audio -boot c -fda bbe-fd.img -hda bbe-hd.dsk -hdb
vvfat:/TEMP/2

The directory "/TEMP/2" is in the D: drive. It works fine with FreeDOS
Beta9. Unfortunatly, I can't change the path to another drive
(partition).

I tried

/D/TEST/2
D:\TEST\2
/D:/TEST/2

The one introduced is the only one working.

Nice, sorry about my lot wishes, usage of UNC path's...

Great work, really!!

Andreas

RE: [Qemu-devel] Patch: virtual vfat support

[Johannes Schindelin]

Hi,

On Tue, 21 Dec 2004, Andreas Bollhalder wrote:

> D:\TEST\QEMU\qemu.exe -L . -localtime -m 32 -isa -cirrusvga -user-net
> -enable-audio -boot c -fda bbe-fd.img -hda bbe-hd.dsk -hdb
> vvfat:/TEMP/2
>
> The directory "/TEMP/2" is in the D: drive. It works fine with FreeDOS
> Beta9. Unfortunatly, I can't change the path to another drive
> (partition).
>
> I tried
>
> /D/TEST/2
> D:\TEST\2
> /D:/TEST/2

Of course this doesn't work. As D:\ is already the host directory /TEMP/2,
you would try to change to /TEMP/2/TEMP/2 with this command.

BTW, what exactly do you mean by "another drive" and "partition"? The
VVFAT driver transparently builds a hard disk image for your host
directory, which behaves like a drive inside QEmu, having exactly one
partition with a VFAT file system.

BTW(2), if anybody has suggestions for a better name, please tell so.

Hth,
Dscho

Re: [Qemu-devel] Patch: virtual vfat support

[André Braga]

On Wed, 22 Dec 2004 19:55:01 +0100 (CET), Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Of course this doesn't work. As D:\ is already the host directory /TEMP/2,
> you would try to change to /TEMP/2/TEMP/2 with this command.
> 
> BTW, what exactly do you mean by "another drive" and "partition"? The
> VVFAT driver transparently builds a hard disk image for your host
> directory, which behaves like a drive inside QEmu, having exactly one
> partition with a VFAT file system.

You misunderstood what he meant. On his *host* system, the D drive
holds the temp\2 directory, as in d:\temp\2. QEMU is also installed in
the D drive/partition, so specifying /TEMP/2 goes to the root of the
filesystem in this partition. He couldn't figure out a way to change
to another path in another partition/drive, say, e:\temp\qemu , or
even a CD drive letter: having a virtual VFAT partition built on top
of a CD directory structure would work around having to make a ISO
image of the disk in a considerable number of situations.

I haven't tested your patch yet, so I can't say I figured how to
change drives myself. Maybe \\.\e\temp\qemu as in my example above?
I've seen such UNC convention work in QEMU before (more specifically
the discussions on Japanese Knoppix and QEMU).



-- 
"The weakest way to solve a problem is just to solve it"
-Alan Kay

[Qemu-devel] Re: Patch: virtual vfat support

[Ronald]

Le Wed, 22 Dec 2004 23:02:26 -0200, André Braga a écrit :

> I haven't tested your patch yet, so I can't say I figured how to change
> drives myself. Maybe \\.\e\temp\qemu as in my example above? I've seen
> such UNC convention work in QEMU before (more specifically the discussions
> on Japanese Knoppix and QEMU).
 
To export a directory on another drive just put two backslaches instead of
only one like this vvfat:d:\\temp, I have not tried with cdrom drives,
just hard drives

RE: [Qemu-devel] Patch: virtual vfat support

[Andreas Bollhalder]

> You misunderstood what he meant. On his *host* system, the D drive
> holds the temp\2 directory, as in d:\temp\2. QEMU is also installed
in
> the D drive/partition, so specifying /TEMP/2 goes to the root of the
> filesystem in this partition. He couldn't figure out a way to change
> to another path in another partition/drive, say, e:\temp\qemu , or
> even a CD drive letter: having a virtual VFAT partition built on top
> of a CD directory structure would work around having to make a ISO
> image of the disk in a considerable number of situations.

That's right, but I know now why, it's because the directories on
other host drives have been holding more data the vvfat drive could
represent and QEmu quits without a message. Now I know that, I can use
other host drives too.

> I haven't tested your patch yet, so I can't say I figured how to
> change drives myself. Maybe \\.\e\temp\qemu as in my example above?
> I've seen such UNC convention work in QEMU before (more specifically
> the discussions on Japanese Knoppix and QEMU).

This would be the nice way. Or maybe one likes more an URL like
"sftp://myhost.mydomain/mydir/myimage" ?

Andreas

___________________________________________
IDEEN UND ZEIT SIND UMGEKEHRT PROPORTIONAL.

[Qemu-devel] Patch: virtual vfat support

[Johannes Schindelin]

Hi,

I proudly present the alpha version of my vvfat block driver:

http://libvncserver.sf.net/qemu/qemu-vvfat.patch.gz

So what is it? By calling QEmu with "-hda vvfat:some/directory", you can
access the files in that directory via an emulated (virtual) VFAT device.
(Yes, from the guest OS you can read the files and subdirectories of one
of the host OS' directories, and yes, this should eventually solve the SMB
on DOS problem).

Warning: this is the first alpha version (read only). 2nd warning: If you
access the files from within QEmu and change the contents from without,
you're likely to get corrupt data inside QEmu.

How it works: It fakes an mbr, as well as one partition with boot sector
FAT and directory. The rest of that partition is transparently mapped to
the files in the local directory. I used a fixed big size of this virtual
hard drive, because as it is all fake, space is cheap...

When the directory is built, the block driver recurses into the given
directory, and "stores" them just after the 2nd FAT. After that, the FAT
is built, "storing" all files subsequently at the first "free" clusters.

Why VFAT? Because almost every OS has support for it, at least now that
every digital camera and USB stick and maybe even your washing machine is
using it. And chances are good that Microschrott cannot patent it, much as
it may try.

It works with a Linux guest. I tried with FreeDOS, but it's not able to
access the hard disk. Why doesn't it work with FreeDOS? No idea. This is
my priority for now. Although, if you want to help, you're so welcome.

After that, I will try to add write support. This will be a little bit of
guess work, as QEmu cannot be completely sure in which order the
transaction (write new sector, write FAT, write directory entry) will
happen. Maybe it's possible to trigger the update whenever the last of
those three actions happened. I don't know. I am tired.

Ciao,
Dscho

Re: [Qemu-devel] Patch: virtual vfat support

[Magnus Damm]

Hello,

Great idea, really cool! Now if someone could add USB support and we
could hook up your code as an virtual USB storage device, then
hotplugging could then be used to update the state of the
filesystem...

/ magnus

On Sun, 19 Dec 2004 19:15:18 +0100 (CET), Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
> 
> I proudly present the alpha version of my vvfat block driver:
> 
> http://libvncserver.sf.net/qemu/qemu-vvfat.patch.gz
> 
> So what is it? By calling QEmu with "-hda vvfat:some/directory", you can
> access the files in that directory via an emulated (virtual) VFAT device.
> (Yes, from the guest OS you can read the files and subdirectories of one
> of the host OS' directories, and yes, this should eventually solve the SMB
> on DOS problem).
> 
> Warning: this is the first alpha version (read only). 2nd warning: If you
> access the files from within QEmu and change the contents from without,
> you're likely to get corrupt data inside QEmu.
> 
> How it works: It fakes an mbr, as well as one partition with boot sector
> FAT and directory. The rest of that partition is transparently mapped to
> the files in the local directory. I used a fixed big size of this virtual
> hard drive, because as it is all fake, space is cheap...
> 
> When the directory is built, the block driver recurses into the given
> directory, and "stores" them just after the 2nd FAT. After that, the FAT
> is built, "storing" all files subsequently at the first "free" clusters.
> 
> Why VFAT? Because almost every OS has support for it, at least now that
> every digital camera and USB stick and maybe even your washing machine is
> using it. And chances are good that Microschrott cannot patent it, much as
> it may try.
> 
> It works with a Linux guest. I tried with FreeDOS, but it's not able to
> access the hard disk. Why doesn't it work with FreeDOS? No idea. This is
> my priority for now. Although, if you want to help, you're so welcome.
> 
> After that, I will try to add write support. This will be a little bit of
> guess work, as QEmu cannot be completely sure in which order the
> transaction (write new sector, write FAT, write directory entry) will
> happen. Maybe it's possible to trigger the update whenever the last of
> those three actions happened. I don't know. I am tired.
> 
> Ciao,
> Dscho
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>

Re: [Qemu-devel] Patch: virtual vfat support

[Johannes Schindelin]

Hi,

On Sun, 19 Dec 2004, Magnus Damm wrote:

> Great idea, really cool! Now if someone could add USB support and we
> could hook up your code as an virtual USB storage device, then
> hotplugging could then be used to update the state of the
> filesystem...

If you have an OS advanced enough to support USB (Windows NT isn't, for
example...), you'd expect it to support SMB out of the box, right?

Besides, I don't think that it's as easy to support USB as it was writing
the vvfat driver.

Ciao,
Dscho

Re: [Qemu-devel] Patch: virtual vfat support

[Magnus Damm]

Hello,

On Sun, 19 Dec 2004 20:44:26 +0100 (CET), Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> If you have an OS advanced enough to support USB (Windows NT isn't, for
> example...), you'd expect it to support SMB out of the box, right?

Yes, true, but I would like to see a solution where filesystems could
be exported from the host to the guest without adding extra
dependencies on the host system. To make QMEU as self-contained as
possible.

> Besides, I don't think that it's as easy to support USB as it was writing
> the vvfat driver.

I think the hardest part would be to emulate the USB controller chip
attached to the PCI bus. Emulating simple USB devices on top of that
is probably not very complicated.

And I think read-only wfat is doable but I am not sure if operating
systems would work with a read-write implementation where the host
adds data to the wfat filesystem - I mean, how do we notify the guest
operating system that directories or files have changed?

Another approach instead of USB storage + wfat could be to emulate an
ISO 9660 filesystem together with a virtual cdrom drive and let a
virtual eject+insert operation be a "refresh" operation...

Thanks,

/ magnus

Re: [Qemu-devel] Patch: virtual vfat support

[Johannes Schindelin]

Hi,

On Sun, 19 Dec 2004, Magnus Damm wrote:

> And I think read-only wfat is doable

Yes, it is. That is exactly what my patch does.

> but I am not sure if operating systems would work with a read-write
> implementation where the host adds data to the wfat filesystem - I mean,
> how do we notify the guest operating system that directories or files
> have changed?

If it is no networked file system, then there is no way... apart from
using a removable device, like you suggested. But having implemented
FAT16, I'd rather go for FAT12 (floppy disks), because even DOS can work
with floppy disks out of the box, while it cannot do that with ISO9660,
let alone CDROM drives.

Ciao,
Dscho

RE: [Qemu-devel] Patch: virtual vfat support

[Andreas Bollhalder]

> On Sun, 19 Dec 2004, Magnus Damm wrote:
> 
> > but I am not sure if operating systems would work with a
read-write
> > implementation where the host adds data to the wfat 
> filesystem - I mean,
> > how do we notify the guest operating system that 
> directories or files
> > have changed?
> 
> If it is no networked file system, then there is no way... apart
from
> using a removable device, like you suggested. But having implemented
> FAT16, I'd rather go for FAT12 (floppy disks), because even 
> DOS can work
> with floppy disks out of the box, while it cannot do that 
> with ISO9660,
> let alone CDROM drives.

I vote for a "networked file system" with an small guest driver...
especially for DOS.

Andreas

RE: [Qemu-devel] Patch: virtual vfat support

[Johannes Schindelin]

Hi,

On Mon, 20 Dec 2004, Andreas Bollhalder wrote:

> I vote for a "networked file system" with an small guest driver...
> especially for DOS.

Okay. Details? Technical suggestions?

Ciao,
Dscho

Re: [Qemu-devel] Patch: virtual vfat support

[Panagiotis Issaris]

Hi,

Johannes Schindelin wrote:

>Hi,
>
>On Sun, 19 Dec 2004, Magnus Damm wrote:
>
>  
>
>>Great idea, really cool! Now if someone could add USB support and we
>>could hook up your code as an virtual USB storage device, then
>>hotplugging could then be used to update the state of the
>>filesystem...
>>    
>>
>
>If you have an OS advanced enough to support USB (Windows NT isn't, for
>example...), you'd expect it to support SMB out of the box, right?
>
>Besides, I don't think that it's as easy to support USB as it was writing
>the vvfat driver.
>  
>
Could this be useful:
http://usbip.sourceforge.net/

With friendly regards,
Takis

-- 
------------------------------------------------------------------------
Panagiotis Issaris
Katholieke Universiteit Leuven
Division Production Engineering,
Machine Design and Automation
Celestijnenlaan 300B              panagiotis.issaris@mech.kuleuven.ac.be
B-3001 Leuven Belgium                 http://www.mech.kuleuven.ac.be/pma
------------------------------------------------------------------------

Re: [Qemu-devel] Patch: virtual vfat support

[Johannes Schindelin]

Hi,

On Sun, 19 Dec 2004, Panagiotis Issaris wrote:

> Johannes Schindelin wrote:
>
> >Besides, I don't think that it's as easy to support USB as it was writing
> >the vvfat driver.
> >
> >
> Could this be useful:
> http://usbip.sourceforge.net/

I could be wrong there, but I think this is a middle layer for linux,
which behaves like a USB driver, but doesn't really emulate the hardware,
right?

This could therefore be used inside QEmu for Linux guests.

Ciao,
Dscho

Re: [Qemu-devel] Patch: virtual vfat support

[zitu]

Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> I proudly present the alpha version of my vvfat block driver:
>
> http://libvncserver.sf.net/qemu/qemu-vvfat.patch.gz

It does not compile out of the box on windows host. I had to add
a locatime_r.c to make it compile successfully.

======================================================================
#include <errno.h>
#include <time.h>

struct tm *
localtime_r(const time_t *t, struct tm *ptm)
{
    struct tm *ptms = localtime(t); /* pointer to static structure */

    if (ptms)
    {
	*ptm = *ptms;
	return ptm;
    }
    else
    {
	return 0;
    }
}
======================================================================

> So what is it? By calling QEmu with "-hda vvfat:some/directory", you can
> access the files in that directory via an emulated (virtual) VFAT device.
> (Yes, from the guest OS you can read the files and subdirectories of one
> of the host OS' directories, and yes, this should eventually solve the SMB
> on DOS problem).

I tried to install freedos on a disk image, and extract the img to the
local vfat directory. I intended to check read-only capabilities.

Qemu doesn't start at all:
vvqemu.exe -m 160 -L pc-bios -hda vvfat:vfat -cdrom fdbootcd.iso -boot d

vfat contains:
AUTOEXEC.BAT  COMMAND.COM  CONFIG.SYS  FDOS/  FREEDOS.BSS  KERNEL.SYS

Zitu

Re: [Qemu-devel] Patch: virtual vfat support

[Johannes Schindelin]

Hi,

I uploaded a new patch (called version 4 for internal reasons):

http://libvncserver.sf.net/qemu/qemu-vvfat4.patch.gz

It support Win guests and hosts now.

Why didn't it work with FreeDOS? First, I forgot to set total_sectors,
cyls, heads and secs in the BlockDriverState structure. Those are only
needed for accesses via the emulated BIOS, which Linux doesn't do. When I
wrote the cloop and the dmg driver, I only tested with Linux, and those
were fine.

It still didn't work with Win95; I forgot to set the magic first three
bytes of the boot sector. After I fixed that, I still got only the short
names, because I forgot to upcase the short name. This is fixed, too.

I also added name mangling for the short names, so that two different
direntries are guaranteed to have different short names.

I will probably not work on it for a couple of days, in order to do some
real work, so if you want to tackle write support or FAT12 or floppy (no
mbr), go ahead.

Ciao,
Dscho