linux-next: build failure after merge of the net tree

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 4 Oct 2012 10:18:33 +1000

> After merging the net tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> drivers/net/ethernet/chelsio/cxgb4/t4_hw.c: In function 't4_memory_rw':
> drivers/net/ethernet/chelsio/cxgb4/t4_hw.c:420:2: error: implicit declaration of function 'vmalloc' [-Werror=implicit-function-declaration]
> drivers/net/ethernet/chelsio/cxgb4/t4_hw.c:420:7: warning: assignment makes pointer from integer without a cast [enabled by default]
> drivers/net/ethernet/chelsio/cxgb4/t4_hw.c:487:2: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration]
> drivers/net/ethernet/chelsio/cxgb4/t4_hw.c: In function 'get_vpd_params':
> drivers/net/ethernet/chelsio/cxgb4/t4_hw.c:530:6: warning: assignment makes pointer from integer without a cast [enabled by default]
> 
> Caused by commit 8c357ebd5693 ("cxgb4: Dynamically allocate memory in
> t4_memory_rw() and get_vpd_params()").  Missing include of
> linux/vmalloc.h.
> 
> I have used the net tree from next-20121003 for today.

Thanks, I'll fix this as is shown below.

I do have a question though, it is honestly really that much easier to
revert a whole days worth of changes (and therefore not get the code
tested at all) than to simply add the obvious one liner?

It seems to me to be absolutely the wrong tradeoff in these situations.

Hi David,

On Wed, 03 Oct 2012 20:50:53 -0400 (EDT) David Miller <davem@davemloft.net> wrote:
>
> I do have a question though, it is honestly really that much easier to
> revert a whole days worth of changes (and therefore not get the code
> tested at all) than to simply add the obvious one liner?

Actually, for me it is.  I have a script that does the "use yesterday's
version" for me.  To fix (even a one liner) means bringing up an editor,
commiting, creating the patch and then recommiting it (an implementation
detail) and recording that I need to keep (automatically) applying the
patch in case the maintainer doesn't react quickly.

In this particular case I have been telling people to include vmalloc.h
(and other things like slab.h) over and over for years ... its a pain
that x86 builds indirectly include so much stuff.

> It seems to me to be absolutely the wrong tradeoff in these situations.

I guess for the "current/fixes" tree during the merge window, you are
right.  For the "normal" trees, does a delay of (usually) one day really
matter?

I used to fix all this stuff and it added considerably to the length of
my work day (which currently can be up to 16 hours long) :-(

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 4 Oct 2012 11:06:15 +1000

> Actually, for me it is.  I have a script that does the "use yesterday's
> version" for me.  To fix (even a one liner) means bringing up an editor,
> commiting, creating the patch and then recommiting it (an implementation
> detail) and recording that I need to keep (automatically) applying the
> patch in case the maintainer doesn't react quickly.

Ok, fair enough.

I'll try to look into making x86 barf when a vmalloc.h include is
missing.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

David and Stephen,

I apologize for not taking the necessary steps to verify our patches
before submission. Ignorance is not an excuse... Anyways David thank you
for fixing the issue for us.

Jay-

-----Original Message-----
From: David Miller [mailto:davem@davemloft.net] 
Sent: Wednesday, October 03, 2012 6:48 PM
To: sfr@canb.auug.org.au
Cc: netdev@vger.kernel.org; linux-next@vger.kernel.org;
linux-kernel@vger.kernel.org; Vipul Pandya; Jay Hernandez
Subject: Re: linux-next: build failure after merge of the net tree

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 4 Oct 2012 11:06:15 +1000

> Actually, for me it is.  I have a script that does the "use 
> yesterday's version" for me.  To fix (even a one liner) means bringing

> up an editor, commiting, creating the patch and then recommiting it 
> (an implementation
> detail) and recording that I need to keep (automatically) applying the

> patch in case the maintainer doesn't react quickly.

Ok, fair enough.

I'll try to look into making x86 barf when a vmalloc.h include is
missing.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html