lkml.org 
[lkml]   [2005]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/5] Convert resource to u64 from unsigned long
    Dave <dave.jiang@gmail.com> wrote:
    >
    > ere's my first attempt of trying to convert the struct resource
    > start/end to u64 per blessed by Linus =) This is to support >32bit
    > physical address on 32bit archs such as some of the newer ARMv6 and
    > XSC3 based platforms and perhaps IA32 PAE. I left the PCI stuff alone
    > functionally. Supporting 64bit PCI BAR on 32bit archs is for another
    > day. I fixed most of the core stuff I can think of, fixed ARM and i386
    > hopefully and a few of the device drivers as examples. I have tested
    > on an IQ31244 XScale IOP (ARM) platform and a dual-xeon platform for
    > i386. Matt Porter has graciously sent me PPC fixes that he tested on.

    OK, well Greg KH will be the main target of this work..

    Can you do something a bit more friendly than application/octet-stream
    encoding, btw?

    +#if BITS_PER_LONG == 64
    +#define U64FMT "016lx"
    +#else
    +#define U64FMT "016Lx"
    +#endif

    We've avoided doing this. We prefer to do

    printk("%llx", (unsigned long long)foo);

    which is tidier, although a little more runtime-costly.

    Your approach assumes that all 64-bit architectures implement u64 as
    unsigned long (as opposed to unsigned long long, which I guess is legal?) I
    don't know if that's a problem or not.

    Also, the patches introduce tons of ifdefs such as:

    +#if BITS_PER_LONG == 64
    return (void __iomem *)pci_resource_start(pdev, PCI_ROM_RESOURCE);
    +#else
    + return (void __iomem *)(u32)pci_resource_start(pdev, PCI_ROM_RESOURCE);
    +#endif

    We really should find a way of avoiding this. Even if it is

    #if BITS_PER_LONG == 64
    #define resource_to_ptr(r) ((void *)(r))
    #else
    #define resource_to_ptr(r) ((void *)((u32)r))
    #endif

    in a header file somewhere. Open-coding the decision all over the place is
    unsightly.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:09    [W:0.035 / U:60.984 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site