From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Cf5QB-0007YW-Mr for qemu-devel@nongnu.org; Thu, 16 Dec 2004 18:52:35 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Cf5QA-0007Xf-Hb for qemu-devel@nongnu.org; Thu, 16 Dec 2004 18:52:34 -0500 Received: from [129.104.30.34] (helo=mx1.polytechnique.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Cf5Ex-0007EN-BJ for qemu-devel@nongnu.org; Thu, 16 Dec 2004 18:40:59 -0500 Received: from localhost (localhost [127.0.0.1]) by djali.polytechnique.org (Postfix) with ESMTP id A847933195 for ; Fri, 17 Dec 2004 00:40:57 +0100 (CET) Received: from djali.polytechnique.org ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30715-05 for ; Fri, 17 Dec 2004 00:40:57 +0100 (CET) Received: from [84.99.204.74] (unknown [84.99.204.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTP id 6CEAB3317E for ; Fri, 17 Dec 2004 00:40:57 +0100 (CET) Message-ID: <41C21D27.6070409@bellard.org> Date: Fri, 17 Dec 2004 00:41:27 +0100 From: Fabrice Bellard MIME-Version: 1.0 Subject: Re: [Qemu-devel] SMB for DOS ? References: <41C20E6A.7010507@bellard.org> <41C210A3.30406@kadu.net> <41C215DA.4050805@bellard.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Reply-To: 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 Johannes Schindelin wrote: > Hi, > > On Fri, 17 Dec 2004, Fabrice Bellard wrote: > > >>Adrian Smarzewski wrote: >> >>>But I would vote for optimizations! >> >>It was just a suggestion for DOS users :-) >> >>x86 on x86 optimization is now the top item on my TODO list... > > > That's great! > > As for SMB: I had this cute idea of implementing a block driver which > simulates a FAT system, but really uses a local directory as backend. If a > block is accessed, the driver transparently maps it to the block of the > file it belongs to, or returns a read/write error if the block is not > associated with a file. This sounds crazy enough that I might try it > soon... I had also the same idea... and it is already implemented in dosemu (it is only used in the MFS boot process). Implementing it in qemu would be very useful too (and easy given the block devices you already wrote). As in dosemu, it is very important that it can be made bootable (a boot sector must be read from a file or built dynamically). Fabrice.