From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FYzo4-0001Kp-Ns for qemu-devel@nongnu.org; Thu, 27 Apr 2006 02:16:52 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FYzo2-0001H5-FB for qemu-devel@nongnu.org; Thu, 27 Apr 2006 02:16:51 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FYzo2-0001Gx-Cc for qemu-devel@nongnu.org; Thu, 27 Apr 2006 02:16:50 -0400 Received: from [24.93.47.44] (helo=ms-smtp-05.texas.rr.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FYzqt-0007cR-1Z for qemu-devel@nongnu.org; Thu, 27 Apr 2006 02:19:47 -0400 Received: from [192.168.0.11] (cpe-67-9-160-120.austin.res.rr.com [67.9.160.120]) by ms-smtp-05.texas.rr.com (8.13.4/8.13.4) with ESMTP id k3R6Gl6k015391 for ; Thu, 27 Apr 2006 01:16:48 -0500 (CDT) Message-ID: <445061CA.7070605@austin.rr.com> Date: Thu, 27 Apr 2006 01:16:42 -0500 From: Lonnie Mendez MIME-Version: 1.0 Subject: Re: [Qemu-devel] Large USB-Patch Documentation and todays CVS patch References: <444F9D90.9040306@gmx.de> <13040.1146091241@www072.gmx.net> In-Reply-To: <13040.1146091241@www072.gmx.net> Content-Type: text/plain; charset=ISO-8859-1; 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: >I am quite sure you put a lot of work into this patch, but you sure make it >hard to appreciate, too. > >First note that applying such a huge patch is bad. Let me help you (a little >more than last time) to understand that: You are almost guaranteed to >introduce bugs, and what's worse, regressions. Because it is so huge, you >are further guaranteed to have a real hard time tracking that regression. > > Seeing as there is a release coming up this is most definitely not a good thing. Initial testing yielded lots of this. I'd like to see my all-in-one patch stripped out. Then simply modifying the linux redirector to support the improved error handling (have it clear endpoint halt/etc) and other improvements. Later, the new redirectors can be merged in and modified as necessary. The purpose of modifying the user interface to the usb layer also confuses me. What was the reasoning behind changing host:busaddr.addr to host:busaddr:addr and host:VID:PID to host:VIDxPID? This is something that should be abstracted in the layer and not handed down to the user. Why display the bcdUSB revision and not the connected speed to the user (as is already done)? To argue that this must all go in at once or none at all is silly. I've seen the changes and know that my redirectors aren't necessary for this to function. I'm not trying to get anyone down on this but am just saying this needs more discussion and thought.