Re: [Qemu-devel] Large USB-Patch Documentation and todays CVS patch

[Per Åstrand]

Hello!

I just wanted to hear about the Large USB patch that was discussed quite alot here a couple of months ago.
As I understood it the patch was put on hold until the 0.90 release, but I've heard nothing more about it...

Is anybody (Tino, Lonnie?) working on getting the patch into CVS?

Would be a shame if all the hard work was lost and someone had to start from scratch...

/Per

>  Sun, 20 Aug 2006 09:05:33 -0700
> Joseph Miller
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> With all due respect, Tino Seifert, I must comment on your USB patch.  I do 
> not normally post to this list, but I follow it very closely as the project 
> 
> is of great interest to me.  I must admit that I have rarely even looked at 
> qemu code, and that I have never even looked at your USB patch.  Personally, 
> I can't wait for a USB patch to come out that will make USB life much easier.  
> 
> Qemu is a project that is about what the people want, and I think that the 
> people want USB to work.  However, the first people that you must work with 
> are the other developers.  If you wrote the greatest patch/bugfix that Qemu 
> 
> has ever seen, but you piss everyone off, no one will listen to you, and the 
> many people that could have benefited from the patch will never see it's 
> effects.  I think that everyone on the list would love to see improvement to 
> 
> the USB functionality.  We can all see that you have placed an immense amount 
> of time and effort making this come to fruition.  It sucks when so much time 
> is spent on a project, especially one that works so well and has so much to 
> 
> offer, yet it must be delayed or modified to meet the expectations of the 
> others.  There are probably few people who know the Qemu USB code better than 
> you do.  Unfortunately, this becomes your problem.  I think that most people 
> 
> want to see your patch integrated, but not all at once.  I'm sure that it 
> will require some serious re-working in order to satisfy the demands of the 
> other developers.  But policies are in place for a reason.  Someone, 
> 
> somewhere, long ago in the history of coding, wrote lots of big patches every 
> time they wanted to modify code, and they screwed it up beyond recognition.  
> This may not be your fault, but you must pay the price for it.
> 
> 
> Suffice this to say, I would love to see your USB changes come about and I 
> can't wait to test this once it is applied to CVS, but if changes in that 
> patch don't come about, it will never happen.  And somewhere down the line, 
> 
> probably months later, someone else will send in the same work that you did, 
> in smaller chunks, they will work hard to try and cooperate with other 
> demanding developers, and they will get all the credit for all of the work 
> 
> that you have already done.  Please, I beg of you, make your patch 
> worthwhile, make the requested changes, or I fear that we will never see your 
> work.
> 
> Sincerely,
> 
> - -Joseph, A Discouraged Qemu User
> 
> 
> On Thursday 27 April 2006 11:45 am, [EMAIL PROTECTED] wrote:
> > Hello Lonnie.
> >
> > Lonnie Mendez wrote:
> > > Johannes Schindelin wrote:
> > >
> > >
> > >   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.
> >
> > Nobody said anything about a short to come release. I have no problem to
> 
> > suspend the patch until after this release. But then usb should stay as
> > untouched as possible.
> >
> > >   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)?
> >
> > The reason was a simple thougth of mine: a linux user could probably
> > better understand bus:device (it is something which he gets displayed
> > sometimes from libusb: libusb:001:002) but I m really open to change it
> 
> > to whatever string you want. A other possibility is that we introduce
> > something like hostid:VID:PID. I can only tell you that I do not
> > completely like the old notation. (But as I said before, no hard
> 
> > feelings about that, it is changed in less than a minute)
> >
> > The reason for the bcdUSB revision is even simpler. A person who has
> > only used USB has no idea what full speed or lowspeed does mean. If you
> 
> > look through the code you will notice that the speed setting was
> > determined by bcdUSB and so I thougth it may be better to display it. As
> > most people have a idea what USB 1.0
, 1.1 or 2.0 means.
> 
> >
> > With kind regards,
> > Tino H. Seifert
> >
> >
> > _______________________________________________
> > Qemu-devel mailing list
> > address@hidden
> 
> > http://lists.nongnu.org/mailman/listinfo/qemu-devel
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> 
> 
> iD8DBQFEUgHnmXZROF+EADURAtGkAJ43Iv/1wYTGK3RyNhiSPTiSet3T9wCbBC9H
> +n+Tuu0lW1C8iwxs1bF20dc=
> =s9uJ
> -----END PGP SIGNATURE-----
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> 
> address@hidden
> 
http://lists.nongnu.org/mailman/listinfo/qemu-devel
>