From: James Bottomley <James.Bottomley@suse.de>
To: Stefani Seibold <stefani@seibold.net>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Jiri Kosina <jkosina@suse.cz>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-scsi <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH] libsrp: fix compile failure
Date: Mon, 04 Jan 2010 13:37:17 -0600 [thread overview]
Message-ID: <1262633838.2724.218.camel@mulgrave.site> (raw)
In-Reply-To: <1262633054.4814.21.camel@wall-e>
On Mon, 2010-01-04 at 20:24 +0100, Stefani Seibold wrote:
> Am Montag, den 04.01.2010, 17:35 +0000 schrieb Alan Cox:
> > > least once before it goes to Linus. There were originally technical
> > > reasons why -mm wasn't in ... I just thought they'd been fixed by now.
> >
> > No - mm also caused problems with the kfifo merge of a core API change
> > that didn't go via -next.
> >
> > Alan
>
> I tried my best to port everything to the new kfifo API. But it was not
> possible to check it against every architecture.
That's what linux-next is for: to make at least this compile checking
against all of our architectures more of a reality. It's still missing
bits, and some of the ports (*cough* parisc *cough*) compile against
linux-next rather infrequently, but it's far better than nothing.
> x86 and x86_64 was
> compile clean. I think the missing #include was not a big thing.
It's easily fixable, yes ... breaking the build *is* a pretty big thing
because of the fallout it causes (for ppc: about ~100 instant WTF
moments followed by grubbing around in git to find the cause).
It's also an indicator of future problems. Realistically, all API
changes should go into linux-next both to prevent this sort of thing
from happening and to see if we have any other pending conflicts that
may cause problems.
James
next prev parent reply other threads:[~2010-01-04 19:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-30 19:21 [PATCH] libsrp: fix compile failure James Bottomley
2009-12-30 19:33 ` Linus Torvalds
2009-12-30 19:55 ` James Bottomley
2010-01-04 15:21 ` Jiri Kosina
2010-01-04 17:22 ` James Bottomley
2010-01-04 17:35 ` Alan Cox
2010-01-04 19:24 ` Stefani Seibold
2010-01-04 19:37 ` James Bottomley [this message]
2010-01-04 22:36 ` Alan Cox
2010-01-04 21:12 ` Jiri Kosina
2010-01-04 21:35 ` Andrew Morton
2010-01-04 22:00 ` Jiri Kosina
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1262633838.2724.218.camel@mulgrave.site \
--to=james.bottomley@suse.de \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=jkosina@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=stefani@seibold.net \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox