Hi Andrew,
After merging the akpm tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
In file included from include/linux/printk.h:6:0,
from include/linux/kernel.h:13,
from include/linux/list.h:8,
from mm/z3fold.c:26:
Hi Andrew,
After merging the akpm tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
In file included from include/linux/printk.h:6:0,
from include/linux/kernel.h:13,
from include/linux/list.h:8,
from mm/z3fold.c:26:
On Thu, Nov 29, 2012 at 05:19:39PM +1100, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (x86_64
> allmodconfig) produced these warnings:
> In file included from drivers/block/drbd/drbd_bitmap.c:32:0:
> drivers/block/drbd/drbd_int.h:2339:0:
Hi Andrew,
After merging the akpm tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:
In file included from drivers/block/drbd/drbd_bitmap.c:32:0:
drivers/block/drbd/drbd_int.h:2339:0: warning: "__wait_event_lock_irq"
redefined [enabled by default]
Hi Andrew,
After merging the akpm tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:
In file included from drivers/block/drbd/drbd_bitmap.c:32:0:
drivers/block/drbd/drbd_int.h:2339:0: warning: __wait_event_lock_irq
redefined [enabled by default]
On Thu, Nov 29, 2012 at 05:19:39PM +1100, Stephen Rothwell wrote:
Hi Andrew,
After merging the akpm tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:
In file included from drivers/block/drbd/drbd_bitmap.c:32:0:
drivers/block/drbd/drbd_int.h:2339:0: warning:
Am Freitag, den 26.10.2012, 06:36 +0800 schrieb Richard Yang:
> >
> >And holy cow that code is hard to read :( Why was kfifo_in()
> >implemented as a macro, anyway? AFAICT all its args have a known type,
> >so we could have used a proper C interface, which would have fixed all
> >this nicely.
>
Hi Andrew,
On Thu, 25 Oct 2012 15:23:37 -0700 Andrew Morton
wrote:
>
> Anyway,
> include-linux-kfifoh-replace-open-coded-type-check-code-with-typecheck.patch
> takes the kfifo typechecking from "too strict" to "far too strict", so
> I'll drop that patch.
I have dropped it from the akpm tree in
On Thu, 25 Oct 2012 22:12:32 +0800
Richard Yang wrote:
> >drivers/scsi/libiscsi.c: In function 'iscsi_free_task':
> >drivers/scsi/libiscsi.c:507:2: warning: comparison of distinct pointer types
> >lacks a cast [enabled by default]
> >drivers/scsi/libiscsi.c: In function 'iscsi_pool_init':
>
Hi Richard,
On Thu, 25 Oct 2012 21:09:52 +0800 Richard Yang
wrote:
>
> On Thu, Oct 25, 2012 at 02:28:54PM +1100, Stephen Rothwell wrote:
> >
> >After merging the akpm tree, today's linux-next build (powerpc
> >ppc64_defconfig) produced these warnings:
> >
>
Hi Richard,
On Thu, 25 Oct 2012 22:12:32 +0800 Richard Yang
wrote:
>
> I did a quick check.
>
> The root reason is,
> 1. kfifo_in() second parameter should be type "const void *"
> 2. kfifo_out_locked() second parameter should be type "void *"
> 3. kfifo_in_locked() second parameter should
Hi Richard,
On Thu, 25 Oct 2012 22:12:32 +0800 Richard Yang weiy...@linux.vnet.ibm.com
wrote:
I did a quick check.
The root reason is,
1. kfifo_in() second parameter should be type const void *
2. kfifo_out_locked() second parameter should be type void *
3. kfifo_in_locked() second
Hi Richard,
On Thu, 25 Oct 2012 21:09:52 +0800 Richard Yang weiy...@linux.vnet.ibm.com
wrote:
On Thu, Oct 25, 2012 at 02:28:54PM +1100, Stephen Rothwell wrote:
After merging the akpm tree, today's linux-next build (powerpc
ppc64_defconfig) produced these warnings:
On Thu, 25 Oct 2012 22:12:32 +0800
Richard Yang weiy...@linux.vnet.ibm.com wrote:
drivers/scsi/libiscsi.c: In function 'iscsi_free_task':
drivers/scsi/libiscsi.c:507:2: warning: comparison of distinct pointer types
lacks a cast [enabled by default]
drivers/scsi/libiscsi.c: In function
Hi Andrew,
On Thu, 25 Oct 2012 15:23:37 -0700 Andrew Morton a...@linux-foundation.org
wrote:
Anyway,
include-linux-kfifoh-replace-open-coded-type-check-code-with-typecheck.patch
takes the kfifo typechecking from too strict to far too strict, so
I'll drop that patch.
I have dropped it from
Am Freitag, den 26.10.2012, 06:36 +0800 schrieb Richard Yang:
And holy cow that code is hard to read :( Why was kfifo_in()
implemented as a macro, anyway? AFAICT all its args have a known type,
so we could have used a proper C interface, which would have fixed all
this nicely.
Thats
Hi Andrew,
On Thu, 25 Oct 2012 14:28:54 +1100 Stephen Rothwell
wrote:
>
> After merging the akpm tree, today's linux-next build (powerpc
> ppc64_defconfig) produced these warnings:
>
> drivers/infiniband/hw/cxgb3/cxio_resource.c: In function
> '__cxio_init_resource_fifo':
>
Hi Andrew,
After merging the akpm tree, today's linux-next build (powerpc
ppc64_defconfig) produced these warnings:
drivers/infiniband/hw/cxgb3/cxio_resource.c: In function
'__cxio_init_resource_fifo':
drivers/infiniband/hw/cxgb3/cxio_resource.c:62:3: warning: comparison of
distinct pointer
Hi Andrew,
After merging the akpm tree, today's linux-next build (powerpc
ppc64_defconfig) produced these warnings:
drivers/infiniband/hw/cxgb3/cxio_resource.c: In function
'__cxio_init_resource_fifo':
drivers/infiniband/hw/cxgb3/cxio_resource.c:62:3: warning: comparison of
distinct pointer
Hi Andrew,
On Thu, 25 Oct 2012 14:28:54 +1100 Stephen Rothwell s...@canb.auug.org.au
wrote:
After merging the akpm tree, today's linux-next build (powerpc
ppc64_defconfig) produced these warnings:
drivers/infiniband/hw/cxgb3/cxio_resource.c: In function
'__cxio_init_resource_fifo':
20 matches
Mail list logo
