* Michael Buesch <[email protected]> wrote:
> On Friday 14 December 2007 02:12:25 Ray Lee wrote:
> > Digging a little farther into it, it looks like b43 is barfing partway
> > through init as the firmware file it's looking for has changed names.
> > Perhaps that's the issue. I'll take a longer look at this all
> > tomorrow.
>
> http://www.linuxwireless.org/en/users/Drivers/b43#firmwareinstallation
>
> > Well, it only hit the main kernel October 10th. That means no final
> > point release of the kernel.org kernel has even had it included! So
> > testing-wise, you still haven't hit the hordes yet. Scheduling a
> > removal of bcm43xx (as painful as that code is [*]), seems either
> > premature or very optimistic. So, how about scheduling the removal
> > once you get a feel for the bug reports that'll come in once 2.6.24 is
> > released.
>
> So you volunteer to maintain bcm43xx? Fine. Thanks a lot.
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
