qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Joseph Miller
Subject: Re: [Qemu-devel] Large USB-Patch Documentation and todays CVS patch
Date: Fri, 28 Apr 2006 12:44:54 -0000
User-agent: KMail/1.6.2

-----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, address@hidden 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-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]