linux-kernel - Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200712150225.52183.rjw@sisk.pl>
Date:	Sat, 15 Dec 2007 02:25:50 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Michael Buesch <mb@...sch.de>
Cc:	bcm43xx-dev@...ts.berlios.de, Ingo Molnar <mingo@...e.hu>,
	Daniel Walker <dwalker@...sta.com>, akpm@...ux-foundation.org,
	stefano.brivio@...imi.it, Ray Lee <ray-lk@...rabbit.org>,
	matthias.kaehlcke@...il.com, linux-kernel@...r.kernel.org,
	linux@...mer.net, jonathan@...masters.org, kjwinchester@...il.com,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	mbuesch@...enet.de
Subject: Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

On Friday, 14 of December 2007, Michael Buesch wrote:
> On Friday 14 December 2007 18:59:10 Ingo Molnar wrote:
> > 
> > * Michael Buesch <mb@...sch.de> wrote:
> > 
> > > In my opinion this all is the work of the distributions and not the 
> > > work of the kernel developers. Distributions have to make sure that 
> > > everything works after a kernel update. [...]
> > 
> > actually, not. The the task of kernel developers is to KEEP OLD 
> > DISTRIBUTIONS WORKING WITH NEW DRIVERS. Or the "old" driver stays around 
> > until eternity, because the new one is just BROKEN.
> 
> What exactly prevents an old distribution from using new b43
> given that they fix their broken udev scripts first?
> 
> (I cannot fix their broken scripts from within the kernel.)

Well, we talked about that some time ago, didn't we?

The rule is this: if one uses kernel 2.6.x from kernel.org _successfully_
with certain distribution (whatever it is), then one is supposed to be able to
take the kernel 2.6.(x+1), install it on that distribution and use it without
any major configuration changes.  If this rule is not followed, people will
stop testing kernel.org kernels and we'll all suffer from that.

Now, in my not so humble opinion, switching from bcm43xx to b43 _is_ a major
configuration change (I did it, so please don't try to discuss with my
experience) and forcing users to do that breaks the rule above.

> > Take a look at CONFIG_COMPAT_VDSO for example - one single version of 
> > glibc was released in a distro that depended on a kernel vDSO bug. So 
> > we'll keep that aspect of the vDSO perhaps forever. Simple as that. 
> > Stuff must just work. Whatever it takes. Best is if you add in new stuff 
> > without the user noticing _ANYTHING_ but that the kernel version bumped. 
> > If the maintainers of the other 7 million lines of kernel code can get 
> > this right then the wireless code should be able to do it too. Ok?
> > 
> > all this "distributors will have to sort out the mess" talk is nonsense, 
> > and i really hope you do not truly believe in that crap. If your 
> > attitude is prevalent in the wireless development community then it's in 
> > worse shape than i thought :-(
> 
> Sorry if I didn't chose my wording correctly. But I was only talking
> about the development of drivers. It is correct that userspace ABI has
> to be preserved, but that is not an issue at all to drivers.
> I was talking about things like installing the right firmware for
> the new driver. It is the job of the distributors to install the new
> firmware when they introduce a new driver.

Yes, as far as new distributions are concerned.  However, we _want_ kernel.org
kernels to work with the old ones too.  Yes, WE DO.

> It is the job of the distributors to test their userland scripts and
> configuration stuff with that driver and fix their stuff. It is _not_ my job
> to fix random distribution udev scripts or explaining over and over again to
> people how the firmware is installed.

Given specific software environment (it may be a home-made system compiled
from sources or whatever), if installing a new kernel forces me to reconfigure
it in any significant way to obtain the functionality that I previously had,
the problem is with the kernel.  No less, no more.

> Either distributions have to install it automatically or people simply have
> to read one or two lines of documentation.  That's just what I wanted to say.

It's not that simple.  For example, regression testing will be a major PITA
if one needs to switch back and forth from the new driver to the old one in the
process.

> Of course it is _my_ job to preserve ABI. I did never want to question that.

Greetings,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/