Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Michael Buesch <mb@...>
Cc: Ray Lee <ray-lk@...>, <bcm43xx-dev@...>, Daniel Walker <dwalker@...>, <akpm@...>, <linux-kernel@...>, <linux@...>, <jonathan@...>, <matthias.kaehlcke@...>, <kjwinchester@...>, <mbuesch@...>, John Linville <linville@...>
Date: Friday, December 14, 2007 - 7:15 am

* Michael Buesch <mb@bu3sch.de> wrote:


it's sad that you are trying to force testers to upgrade to your new 
driver by threatening to unsupport the old driver. The testers who did 
nothing but reported that the new driver did not work on their hardware.

You can write new drivers but you must not break existing users. That's 
true for every single piece of the kernel. It is _your_ responsibility 
to get that rule right - and if it does not work out of box (no matter 
whom to blame, udev or the driver) you dont get to remove the driver 
from the upstream kernel.

Yes, you can then "unsupport it" in spite and be a prick about it in 
general but that will only talk of your own personal qualities and will 
sharply reduce your credibility as a maintainer (and eventually hinder 
your ability to introduce new code) - users will still have the code 
available and will have a chance to fix the driver that happens to work. 
(and perhaps another, capable, but friendler maintainer arises.) And 
that old code will be a clot to drag around, hindering your 'new' 
wireless code all along.

I really dont know why it's so hard to understand: new is totally 
useless if it does not work for old setups 100% of the time. And people 
_WANT_ to use your new code, so it's not like you have to pull their 
hairs to get your stuff tested. And YOU wrote the old code in large 
part:

 $ git-authors drivers/net/wireless/bcm43xx/ | tail -10
      2  Sam Ravnborg
      3  David Howells
      3  David Woodhouse
      3  Joe Perches
      4  Jeff Garzik
      5  Daniel Drake
      6  Stefano Brivio
      9  John W. Linville
     48  Larry Finger
     80  Michael Buesch

so it's not like "someone else messed it up" and that you would be 
incapable of getting it all work nicely and make the migration of users 
smoother. And if udev is a hindrance to you, reduce your driver's 
dependence on udev breakages.

	Ingo
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semap..., Ingo Molnar, (Fri Dec 14, 7:15 am)
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semap..., Rafael J. Wysocki, (Fri Dec 14, 8:51 pm)
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semap..., Rafael J. Wysocki, (Sat Dec 15, 7:18 pm)
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semap..., Rafael J. Wysocki, (Sun Dec 16, 10:35 am)
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semap..., John W. Linville, (Fri Dec 14, 10:14 am)
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semap..., John W. Linville, (Thu Dec 13, 10:23 am)