From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Cg6xj-0001ZT-RP for qemu-devel@nongnu.org; Sun, 19 Dec 2004 14:43:28 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1Cg6xj-0001Yo-5W for qemu-devel@nongnu.org; Sun, 19 Dec 2004 14:43:27 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Cg6xj-0001Yi-3d for qemu-devel@nongnu.org; Sun, 19 Dec 2004 14:43:27 -0500 Received: from [64.233.184.200] (helo=wproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Cg6n9-0000rT-Uj for qemu-devel@nongnu.org; Sun, 19 Dec 2004 14:32:32 -0500 Received: by wproxy.gmail.com with SMTP id 63so56693wri for ; Sun, 19 Dec 2004 11:32:30 -0800 (PST) Message-ID: Date: Sun, 19 Dec 2004 20:32:30 +0100 From: Magnus Damm Subject: Re: [Qemu-devel] Patch: virtual vfat support In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Reply-To: Magnus Damm , qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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 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 >