From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KnGyg-0007co-Ld for qemu-devel@nongnu.org; Tue, 07 Oct 2008 14:08:10 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KnGyg-0007cR-96 for qemu-devel@nongnu.org; Tue, 07 Oct 2008 14:08:10 -0400 Received: from [199.232.76.173] (port=44522 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KnGyg-0007cN-0Z for qemu-devel@nongnu.org; Tue, 07 Oct 2008 14:08:10 -0400 Received: from fg-out-1718.google.com ([72.14.220.154]:40627) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KnGye-0004sK-W0 for qemu-devel@nongnu.org; Tue, 07 Oct 2008 14:08:09 -0400 Received: by fg-out-1718.google.com with SMTP id l26so4238294fgb.8 for ; Tue, 07 Oct 2008 11:08:05 -0700 (PDT) Message-ID: Date: Tue, 7 Oct 2008 21:08:05 +0300 From: "Blue Swirl" Subject: Re: [Qemu-devel] [PATCH] USB over network In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: 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 On 10/7/08, Gal Hammer wrote: > > How about USB drives or printers, do they work? > > > Basically, if it works locally, it should work over network. The remote feature should be as good as the qemu's current support for USB emulation. > > > > A few comments: > > - 'static' can be applied to a lot of functions > > > I'll search for these. > > > > - instead of including linux/usb_ch9.h, you should define the > > structures, like in usb-linux.c > > > No problem. > > > > - while the daemon is linux specific, the remote protocol looks like > > host OS neutral, so it should not be too tightly tied to usb-linux.c > > > The protocol is still in its pre-draft status. I meant that also Windows and BSD clients could in theory use a USB device from the Linux-only server, so the client end of the protocol should be independent from usb-linux.c. > > - name __ioctl looks like it could clash with system defines and it's > > not very descriptive > > > Will changed (Do you have an idea how to name it?). USBRemoteIOCTLFunc? > > - USB_REMOTE_MAGIC is not endian neutral, or is that the purpose? > > > I didn't understand. Do you mean that the value might change if qemu is running on a different type of CPU? Yes. That would cause problems if the server is different endian from the client. In fact the whole protocol looks like it also assumes that the server and client are same endian.