linux-kernel - Re: [Ksummit-2012-discuss] [ATTEND or not ATTEND] That's the question!

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]

Date:	Tue, 19 Jun 2012 09:45:51 -0600
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	ksummit-2012-discuss@...ts.linux-foundation.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [Ksummit-2012-discuss] [ATTEND or not ATTEND] That's the question!

On Fri, Jun 15, 2012 at 4:56 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
>   - How do we cope with the need to review the increasing amount of
>     (insane) patches and their potential integration?

There's certainly a problem here.  Sometimes I see patches that are
technically correct, but there's a philosophical discussion about
whether a design or user interface change is desirable.  Those are fun
and interesting to deal with.

The bigger problem for me is that many patches do something useful and
desirable but have some obscure technical problem, and it's hard to
catch them.  Usually these patches come from competent submitters who
merely don't know where all the landmines in the current design are
buried.

As a trivial example, a recent patch added a PCI "final" fixup.  Seems
perfectly reasonable, except that final fixups aren't applied to
hot-added devices.  That's a bug in PCI, and we shouldn't expect
everybody who writes a quirk to know about it.

We can try to address this by "educating developers" or "documenting
the design better" or "delegating to submaintainers" or whatever.
Those are valuable, but in some way they're cop-outs.  A more
effective fix would be to remove the landmines, reduce complexity, and
improve the design.  If we have coherent code that follows the
hardware architecture and matches people's intuition about how things
"should work," I think we'll get patches with fewer issues.

Sorry, I think I just reiterated what you, Greg KH, Alan, et al have
already said :)
--
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/