linux-kernel - Re: [PATCH] powerpc/ibmveth: fix multiple errors with dma_mapping

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: <20080727200426.c290f14d.akpm@linux-foundation.org>
Date:	Sun, 27 Jul 2008 20:04:26 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	James Morris <jmorris@...ei.org>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Paul Mackerras <paulus@...ba.org>,
	ppc-dev <linuxppc-dev@...abs.org>,
	LKML <linux-kernel@...r.kernel.org>,
	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
	Jeff Garzik <jeff@...zik.org>
Subject: Re: [PATCH] powerpc/ibmveth: fix multiple errors with
 dma_mapping_error conversion

On Mon, 28 Jul 2008 11:07:40 +1000 (EST) James Morris <jmorris@...ei.org> wrote:

> On Mon, 28 Jul 2008, Stephen Rothwell wrote:
> 
> > I hope that we all can discuss procedures for API changes at the Kernel
> > Summit ...
> 
> "all" as in, whoever was invited (the only transparent aspect of was a 
> silly count of # of commits for the initial shortlist), or was on the 
> committee, or bought seats via sponsorship.
> 

Yeah.

We do all our work via email.  If there's some particular issue that we
feel cannot be resolved effectively via email then I'd really like to
know what that issue is, and why.

> - James (co- maintainer/author of several kernel subsystems over 8+ years 
> and apparently not invited, because ?)

- Andrew, who asked everyone two years ago whether we can justify
annual kernel summits, and who still awaits a convincing answer.

But for this particular problem I don't think there's much to be
discussed.  It should have been implemented as
s/dma_mapping_error/dma_mapping_error2/g with eventual removal of
dma_mapping_error().  But I failed to appreciate how many
dma_mapping_error()s there are and I failed to predict how many _new_
dma_mapping_error()s would turn up across the -rc phase.  So I suck,
what's new?

otoh, I don't reeeeeeealy worry too much about compile errors during
the merge window.  People get all hot under the collar and shout at
each other, but they're trivial to find (the compiler tells you!) and
almost always trivial to fix and they are almost always trivially
worked around via config if you hit one during a bisect.  Shrug, fix
them and move on.

It's the runtime errors which are far, far, far more of a problem for us.

--
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/