From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BkRLA-0001lH-If for qemu-devel@nongnu.org; Tue, 13 Jul 2004 13:45:16 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BkRL8-0001ib-Sz for qemu-devel@nongnu.org; Tue, 13 Jul 2004 13:45:16 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BkRL8-0001iX-NJ for qemu-devel@nongnu.org; Tue, 13 Jul 2004 13:45:14 -0400 Received: from [216.254.0.204] (helo=mail4.speakeasy.net) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1BkRIO-0005jC-C8 for qemu-devel@nongnu.org; Tue, 13 Jul 2004 13:42:24 -0400 Received: from dsl081-088-222.lax1.dsl.speakeasy.net (HELO [192.168.111.2]) ([64.81.88.222]) (envelope-sender ) by mail4.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 13 Jul 2004 17:42:15 -0000 Subject: Re: [Qemu-devel] Win98: how to exchange data with Linux From: "John R. Hogerhuis" In-Reply-To: <40F41A65.8050807@volny.cz> References: <200407122356.02502.eschmit@tin.it> <1089671145.12301.10.camel@aragorn> <200407130924.58879.vaise@votreservice.com> <1089727701.7843.58.camel@espiron.av7.local> <40F3EF20.2020802@kadu.net> <40F3F5B1.2040908@kadu.net> <40F41A65.8050807@volny.cz> Content-Type: text/plain Message-Id: <1089740739.17526.3.camel@aragorn> Mime-Version: 1.0 Date: Tue, 13 Jul 2004 10:45:40 -0700 Content-Transfer-Encoding: 7bit Reply-To: jhoger@pobox.com, 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 On Tue, 2004-07-13 at 10:22, Filip Navara wrote: > Adrian Smarzewski wrote: > [snip] > > > It's a windows nt driver for ext2 partitions. maybe we could > > change it so instead of writting files on real drive it will > > pass commands to qemu? file system is not so important, but > > this driver is lgpl'ed. > > At first guys, you confuse file system drivers and storage drivers. The > file system drivers have de facto no knowledge on which disk are the > data located, (on Windows) they recieve an object and send Read/Write > requests to it (well, basicly, in reality there's also the cache manager > between them). At second, the idea can't work, even if you would have a > storage driver that uses some backdoor I/O port to access host disk, the > host OS can't access the same partition at the same time due to things > like caching (on both sides (guest/host)). > Yes, it is a non-workable idea to try to share a filesystem between two running OSes. On a slightly different tack, if your guest OS image was no longer bootable for some reason it would be nice to be able to mount the file system within that image for the purpose of data recovery. Is there a way to do that? -- John.