lkml.org 
[lkml]   [2011]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH V9 3/6] mm: frontswap: core frontswap functionality
    On 09/13/2011 03:50 PM, Dan Magenheimer wrote:
    >> From: Seth Jennings [mailto:sjenning@linux.vnet.ibm.com]
    >> Subject: Re: [PATCH V9 3/6] mm: frontswap: core frontswap functionality
    >>
    >> Hey Dan,
    >>
    >> I get the following compile warnings:
    >>
    >> mm/frontswap.c: In function 'init_frontswap':
    >> mm/frontswap.c:264:5: warning: passing argument 4 of 'debugfs_create_size_t' from incompatible pointer
    >> type
    >> include/linux/debugfs.h:68:16: note: expected 'size_t *' but argument is of type 'long unsigned int *'
    >> mm/frontswap.c:266:5: warning: passing argument 4 of 'debugfs_create_size_t' from incompatible pointer
    >> type
    >> include/linux/debugfs.h:68:16: note: expected 'size_t *' but argument is of type 'long unsigned int *'
    >> mm/frontswap.c:268:5: warning: passing argument 4 of 'debugfs_create_size_t' from incompatible pointer
    >> type
    >> include/linux/debugfs.h:68:16: note: expected 'size_t *' but argument is of type 'long unsigned int *'
    >> mm/frontswap.c:270:5: warning: passing argument 4 of 'debugfs_create_size_t' from incompatible pointer
    >> type
    >> include/linux/debugfs.h:68:16: note: expected 'size_t *' but argument is of type 'long unsigned int *'
    >
    > Thanks for checking on 32-bit!
    >
    >> size_t is platform dependent but is generally "unsigned int"
    >> for 32-bit and "unsigned long" for 64-bit.
    >>
    >> I think just typecasting these to size_t * would fix it.
    >
    > Actually, I think the best fix is likely to change the variables
    > and the debugfs calls to u64 since even on 32-bit, the
    > counters may exceed 2**32 on a heavily-loaded long-running
    > system.
    >

    That was going to be my other suggestion :) I thought I'd suggest
    the route that didn't involve you having to retype the counters. But
    the u64 solution is cleaner and, as Andrew pointed out, less risky.

    > I'll give it a day or two to see if anyone else has any feedback
    > before I fix this for V10.
    >
    > Dan



    \
     
     \ /
      Last update: 2011-09-14 00:01    [W:0.033 / U:0.124 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site