64-bit struct resource fields

64-bit struct resource fields

Post by Dave Hanse » Wed, 27 Nov 2002 01:20:10



We need some way to replicate the e820 tables for kexec.  This
modifies struct resource to use u64's for its start and end fields.
This way we can export the whole e820 table on PAE machines.

resource->flags seems to be used often to mask out things in
resource->start/end, so I think it needs to be u64 too.  But, Is it
all right to let things like pcibios_update_resource() truncate the
resource addresses like they do?

With my config, it has no more warnings than it did before.

Here's /proc/iomem from a 16-gig ia32 box with the patch:

0000000000000000-000000000009c7ff : System RAM
000000000009c800-000000000009ffff : reserved
00000000000a0000-00000000000bffff : Video RAM area
00000000000c0000-00000000000c7fff : Video ROM
00000000000c8000-00000000000cc7ff : Extension ROM
00000000000cc800-00000000000d47ff : Extension ROM
00000000000d4800-00000000000d5fff : Extension ROM
00000000000f0000-00000000000fffff : System ROM
0000000000100000-00000000efff64ff : System RAM
    0000000000100000-000000000029fe78 : Kernel code
    000000000029fe79-0000000000395d7f : Kernel data
00000000efff6500-00000000efffffff : ACPI Tables
00000000f8000000-00000000fbffffff : S3 Inc. Trio 64 3D
00000000fc1e0000-00000000fc1effff : PCI device 1014:00dc (IBM)
00000000fc1fd000-00000000fc1fdfff : Adaptec AIC-7896U2/7897U2 (#2)
    00000000fc1fd000-00000000fc1fdfff : aic7xxx
00000000fc1fe000-00000000fc1fefff : Adaptec AIC-7896U2/7897U2
    00000000fc1fe000-00000000fc1fefff : aic7xxx
00000000fc1ffc00-00000000fc1ffcff : PCI device 1014:00dc (IBM)
00000000fd7c0000-00000000fd7dffff : Intel Corp. 82557/8/9 [Ethernet
00000000fd7fcc00-00000000fd7fcc7f : Digital Equipment Co DECchip 21140
    00000000fd7fcc00-00000000fd7fcc7f : tulip
00000000fd7fd000-00000000fd7fdfff : Intel Corp. 82557/8/9 [Ethernet
    00000000fd7fd000-00000000fd7fdfff : eepro100
00000000fd7fe000-00000000fd7fffff : IBM Netfinity ServeRAID
    00000000fd7fe000-00000000fd7fffff : ips
00000000fe1c0000-00000000fe1dffff : Intel Corp. 82546EB Gigabit Ethe
    00000000fe1c0000-00000000fe1dffff : e1000
00000000fe1e0000-00000000fe1fffff : Intel Corp. 82546EB Gigabit Ethe
    00000000fe1e0000-00000000fe1fffff : e1000
00000000fffb0000-00000000ffffffff : reserved
0000000100000000-00000003ffffffff : System RAM

--
Dave Hansen
haveb...@us.ibm.com

[ 64-bit-resource-2.5.49-0.patch 34K ]
diff -Nru a/arch/alpha/kernel/pci.c b/arch/alpha/kernel/pci.c
--- a/arch/alpha/kernel/pci.c   Fri Nov 22 14:32:09 2002
+++ b/arch/alpha/kernel/pci.c   Fri Nov 22 14:32:09 2002
@@ -149,12 +149,12 @@

 void
 pcibios_align_resource(void *data, struct resource *res,
-                      unsigned long size, unsigned long align)
+                      u64 size, u64 align)
 {
        struct pci_dev *dev = data;
        struct pci_controller *hose = dev->sysdata;
-       unsigned long alignto;
-       unsigned long start = res->start;
+       u64 alignto;
+       u64 start = res->start;

        if (res->flags & IORESOURCE_IO) {
                /* Make sure we start at our min on all hoses */
diff -Nru a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
--- a/arch/arm/kernel/bios32.c  Fri Nov 22 14:32:09 2002
+++ b/arch/arm/kernel/bios32.c  Fri Nov 22 14:32:09 2002
@@ -268,7 +268,7 @@
        int reg;

        if (debug_pci)
-               printk("PCI: Assigning %3s %08lx to %s\n",
+               printk("PCI: Assigning %3s %016Lx to %s\n",
                        res->flags & IORESOURCE_IO ? "IO" : "MEM",
                        res->start, dev->dev.name);

@@ -585,9 +585,9 @@
  * which might be mirrored at 0x0100-0x03ff..
  */
 void pcibios_align_resource(void *data, struct resource *res,
-                           unsigned long size, unsigned long align)
+                           u64 size, u64 align)
 {
-       unsigned long start = res->start;
+       u64 start = res->start;

        if (res->flags & IORESOURCE_IO && start & 0x300)
                start = (start + 0x3ff) & ~0x3ff;
diff -Nru a/arch/i386/kernel/setup.c b/arch/i386/kernel/setup.c
--- a/arch/i386/kernel/setup.c  Fri Nov 22 14:32:10 2002
+++ b/arch/i386/kernel/setup.c  Fri Nov 22 14:32:10 2002
@@ -798,15 +798,18 @@
        probe_roms();
        for (i = 0; i < e820.nr_map; i++) {
                struct resource *res;
-               if (e820.map[i].addr + e820.map[i].size > 0x100000000ULL)
-                       continue;
+              
+               //if (e820.map[i].addr + e820.map[i].size > 0x100000000ULL)
+               //      continue;
+      
                res = alloc_bootmem_low(sizeof(struct resource));
                switch (e820.map[i].type) {
-               case E820_RAM:  res->name = "System RAM"; break;
-               case E820_ACPI: res->name = "ACPI Tables"; break;
-               case E820_NVS:  res->name = "ACPI Non-volatile Storage"; break;
-               default:        res->name = "reserved";
+               case E820_RAM:  res->name = "System RAM e820"; break;
+               case E820_ACPI: res->name = "ACPI Tables e820"; break;
+               case E820_NVS:  res->name = "ACPI Non-volatile Storage e820"; break;
+               default:        res->name = "reserved e820";
                }
+               res->type = e820.map[i].type;
                res->start = e820.map[i].addr;
                res->end = res->start + e820.map[i].size - 1;
                res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
diff -Nru a/arch/i386/pci/i386.c b/arch/i386/pci/i386.c
--- a/arch/i386/pci/i386.c      Fri Nov 22 14:32:09 2002
+++ b/arch/i386/pci/i386.c      Fri Nov 22 14:32:09 2002
@@ -76,10 +76,10 @@
  */
 void
 pcibios_align_resource(void *data, struct resource *res,
-                      unsigned long size, unsigned long align)
+                      u64 size, u64 align)
 {
        if (res->flags & IORESOURCE_IO) {
-               unsigned long start = res->start;
+               u64 start = res->start;

                if (start & 0x300) {
                        start = (start + 0x3ff) & ~0x3ff;
@@ -167,7 +167,7 @@
                        else
                                disabled = !(command & PCI_COMMAND_MEMORY);
                        if (pass == disabled) {
-                               DBG("PCI: Resource %08lx-%08lx (f=%lx, d=%d, p=%d)\n",
+                               DBG("PCI: Resource %016Lx-%016Lx (f=%Lx, d=%d, p=%d)\n",
                                    r->start, r->end, r->flags, disabled, pass);
                                pr = pci_find_parent_resource(dev, r);
                                if (!pr || request_resource(pr, r) < 0) {
diff -Nru a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
--- a/arch/ia64/pci/pci.c       Fri Nov 22 14:32:09 2002
+++ b/arch/ia64/pci/pci.c       Fri Nov 22 14:32:09 2002
@@ -151,7 +151,8 @@
 pcibios_update_resource (struct pci_dev *dev, struct resource *root,
                         struct resource *res, int resource)
 {
-       unsigned long where, size;
+       unsigned long where
+       u64 size;
        u32 reg;

        where = PCI_BASE_ADDRESS_0 + (resource * 4);
@@ -229,7 +230,7 @@

 void
 pcibios_align_resource (void *data, struct resource *res,
-                       unsigned long size, unsigned long align)
+                       u64 size, u64 align)
 {
 }

diff -Nru a/arch/mips/ddb5074/pci.c b/arch/mips/ddb5074/pci.c
--- a/arch/mips/ddb5074/pci.c   Fri Nov 22 14:32:10 2002
+++ b/arch/mips/ddb5074/pci.c   Fri Nov 22 14:32:10 2002
@@ -373,12 +373,12 @@
 }

 void pcibios_align_resource(void *data, struct resource *res,
-                           unsigned long size, unsigned long align)
+                           u64 size, u64 align)
 {
        struct pci_dev *dev = data;

        if (res->flags & IORESOURCE_IO) {
-               unsigned long start = res->start;
+               u64 start = res->start;

                /* We need to avoid collisions with `mirrored' VGA ports
                   and other strange ISA hardware, so we always want the
diff -Nru a/arch/mips/ddb5476/pci.c b/arch/mips/ddb5476/pci.c
--- a/arch/mips/ddb5476/pci.c   Fri Nov 22 14:32:09 2002
+++ b/arch/mips/ddb5476/pci.c   Fri Nov 22 14:32:09 2002
@@ -431,12 +431,12 @@
 }

 void pcibios_align_resource(void *data, struct resource *res,
-                           unsigned long size, unsigned long align)
+                           u64 size, u64 align)
 {
        struct pci_dev *dev = data;

        if (res->flags & IORESOURCE_IO) {
-               unsigned long start = res->start;
+               u64 start = res->start;

                /* We need to avoid collisions with `mirrored' VGA ports
                   and other strange ISA hardware, so we always want the
diff -Nru a/arch/mips/ddb5xxx/common/pci.c b/arch/mips/ddb5xxx/common/pci.c
--- a/arch/mips/ddb5xxx/common/pci.c    Fri Nov 22 14:32:10 2002
+++ b/arch/mips/ddb5xxx/common/pci.c    Fri Nov 22 14:32:10 2002
@@ -165,7 +165,7 @@

 void
 pcibios_align_resource(void *data, struct resource *res,
-                      unsigned long size, unsigned long align)
+                      u64 size, u64 align)
 {
        /* this should not be called */
        MIPS_ASSERT(1 == 0);
diff -Nru a/arch/mips/gt64120/common/pci.c b/arch/mips/gt64120/common/pci.c
--- a/arch/mips/gt64120/common/pci.c    Fri Nov 22 14:32:10 2002
+++ b/arch/mips/gt64120/common/pci.c    Fri Nov 22 14:32:10 2002
@@ -819,12 +819,12 @@
 }

 void pcibios_align_resource(void *data, struct resource *res,
-                           unsigned long size, unsigned long align)
+                           u64 size, u64 align)
 {
        struct pci_dev *dev = data;

        if (res->flags & IORESOURCE_IO) {
-               unsigned long start = res->start;
+               u64 start = res->start;

                /* We need to avoid collisions with `mirrored' VGA ports
                   and other strange ISA hardware, so we always want the
diff -Nru a/arch/mips/ite-boards/generic/it8172_pci.c b/arch/mips/ite-boards/generic/it8172_pci.c
--- a/arch/mips/ite-boards/generic/it8172_pci.c Fri Nov 22 14:32:10 2002
+++ b/arch/mips/ite-boards/generic/it8172_pci.c Fri Nov 22 14:32:10 2002
@@ -183,7 +183,7 @@

 void __init
 pcibios_align_resource(void *data, struct resource *res,
-                      unsigned long size, unsigned long align)
+                      u64 size, u64 align)
 {
     printk("pcibios_align_resource\n");
 }
diff -Nru a/arch/mips/kernel/pci.c b/arch/mips/kernel/pci.c
--- a/arch/mips/kernel/pci.c    Fri Nov 22 14:32:10 2002
+++ b/arch/mips/kernel/pci.c    Fri Nov 22 14:32:10 2002
@@ -162,7 +162,7 @@

 void
 pcibios_align_resource(void *data, struct resource *res,
-                      unsigned long size, unsigned long align)
+                      u64 size, u64 align)
 {
        /* this should not be called */
 }
diff -Nru a/arch/mips/mips-boards/generic/pci.c b/arch/mips/mips-boards/generic/pci.c
--- a/arch/mips/mips-boards/generic/pci.c       Fri Nov 22 14:32:09 2002
+++ b/arch/mips/mips-boards/generic/pci.c       Fri Nov 22 14:32:09 2002
@@ -232,7 +232,7 @@

 void __init
 pcibios_align_resource(void *data, struct resource *res,
-                      unsigned long size, unsigned long align)
+                      u64 size, u64 align)
 {
 }

diff -Nru a/arch/mips/sni/pci.c b/arch/mips/sni/pci.c
--- a/arch/mips/sni/pci.c       Fri Nov 22 14:32:10 2002
+++ b/arch/mips/sni/pci.c       Fri Nov 22 14:32:10 2002
@@ -180,7 +180,7 @@

 void __init
 pcibios_align_resource(void *data, struct resource *res,
-                      unsigned long size, unsigned long align)
+                      u64 size, u64 align)
 {
 }

diff -Nru a/arch/mips64/mips-boards/generic/pci.c b/arch/mips64/mips-boards/generic/pci.c
--- a/arch/mips64/mips-boards/generic/pci.c     Fri Nov 22 14:32:09 2002
+++ b/arch/mips64/mips-boards/generic/pci.c     Fri Nov 22 14:32:09 2002
@@ -291,7 +291,7 @@

 void __init
 pcibios_align_resource(void *data, struct resource *res,
-                      unsigned long size, unsigned long align)
+                      u64 size, u64 align)
 {
 }

diff -Nru a/arch/mips64/sgi-ip27/ip27-pci.c b/arch/mips64/sgi-ip27/ip27-pci.c
--- a/arch/mips64/sgi-ip27/ip27-pci.c   Fri Nov 22 14:32:10 2002
+++ b/arch/mips64/sgi-ip27/ip27-pci.c   Fri Nov 22 14:32:10 2002
@@ -249,7 +249,7 @@

 void __init
 pcibios_align_resource(void *data, struct resource *res,
-                      unsigned long size, unsigned long align)
+                      u64 size, u64 align)
 {
 }

diff -Nru a/arch/mips64/sgi-ip32/ip32-pci.c b/arch/mips64/sgi-ip32/ip32-pci.c
--- a/arch/mips64/sgi-ip32/ip32-pci.c   Fri Nov 22 14:32:10 2002
+++ b/arch/mips64/sgi-ip32/ip32-pci.c   Fri Nov 22 14:32:10 2002
@@ -329,7 +329,7 @@
 }

 void __init pcibios_align_resource (void *data, struct resource *res,
-                                   unsigned long size, unsigned long align)
+                                   u64 size, u64 align)
 {
 }

diff -Nru a/arch/parisc/kernel/pci.c b/arch/parisc/kernel/pci.c
--- a/arch/parisc/kernel/pci.c  Fri Nov 22 14:32:09 2002
+++ b/arch/parisc/kernel/pci.c  Fri Nov 22 14:32:09 2002
@@ -392,11 +392,11 @@
 */
 void __devinit
 pcibios_align_resource(void *data, struct resource *res,
-                      unsigned long size, unsigned long alignment)
+                      u64 size, u64 alignment)
 {
-       unsigned long mask, align;
+       u64 mask, align;

-       DBG_RES("pcibios_align_resource(%s, (%p) [%lx,%lx]/%x, 0x%lx, 0x%lx)\n",
+       DBG_RES("pcibios_align_resource(%s, (%p) [%Lx,%Lx]/%Lx, 0x%Lx, 0x%Lx)\n",
                ((struct pci_dev *) data)->slot_name,
                res->parent, res->start, res->end,
                (int) res->flags, size, alignment);
diff -Nru a/arch/ppc/kernel/pci.c b/arch/ppc/kernel/pci.c
--- a/arch/ppc/kernel/pci.c     Fri Nov 22 14:32:09 2002
+++ b/arch/ppc/kernel/pci.c     Fri Nov 22 14:32:09 2002
@@ -128,7 +128,7 @@
                       "%s/%d (%08x != %08x)\n", dev->slot_name, resource,
                       new, check);
        }
-       printk(KERN_INFO "PCI: moved device %s resource %d
...

read more »

 
 
 

64-bit struct resource fields

Post by Matt Porte » Wed, 27 Nov 2002 18:20:12



> We need some way to replicate the e820 tables for kexec.  This
> modifies struct resource to use u64's for its start and end fields.
> This way we can export the whole e820 table on PAE machines.

> resource->flags seems to be used often to mask out things in
> resource->start/end, so I think it needs to be u64 too.  But, Is it
> all right to let things like pcibios_update_resource() truncate the
> resource addresses like they do?

> With my config, it has no more warnings than it did before.

I could make use of this on my PPC440 systems which have all I/O
(onboard and PCIX host bridge) above 4GB.  However, the patch
I have been playing with typedefs a phys_addr_t so that only
systems which are 32-bit/36-bit+ split like PAE ia32, AUxxxx (MIPS),
and PPC440 have to do long long manipulation.  If you explicitly
use u64 everywhere it forces all native 32-bit/32-bit systems to
do unnecessary long long manipulation.

In the past there has been quite a bit of resistance to even
introducing a physical address typedef due to some claims of
gcc not handling long longs very well [1].  I don't see how
having _everybody_ that is 32-bit native handle long longs is
going to be more acceptable but I could be surprised.

That said, I think when we have existence of systems that require
long long types and gcc is "buggy" in this respect, then using
a phys_addr_t is the lesser of two evils (even though everybody hates
typedefs).  We already have this type defined local to PPC because
it is necessary to cleanly handle ioremap and local page mapping
functionality.  going to u64 or phys_addr_t resources would be a
huge improvement on a horribly kludgy hack we use to crate the
most significant 32-bits for our 64-bit ioremaps.

BTW, since u64 is long long on 32-bit platforms and long on 64-bit
platforms, you will get warnings from every printk that dumps
resource infos.  My thought is to provide some macros to massage
resource values to strings for display.

[1] I get feedback from many people using the PPC440 port and have
    yet to find any instances of gcc mishandling long longs. (though
    this is just anecdotal evidence).

Regards,
--
Matt Porter

This is Linux Country. On a quiet night, you can hear Windows reboot.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

64-bit struct resource fields

Post by Eric W. Biederm » Tue, 03 Dec 2002 06:30:08




> > We need some way to replicate the e820 tables for kexec.  This
> > modifies struct resource to use u64's for its start and end fields.
> > This way we can export the whole e820 table on PAE machines.

> > resource->flags seems to be used often to mask out things in
> > resource->start/end, so I think it needs to be u64 too.  But, Is it
> > all right to let things like pcibios_update_resource() truncate the
> > resource addresses like they do?

> > With my config, it has no more warnings than it did before.

> I could make use of this on my PPC440 systems which have all I/O
> (onboard and PCIX host bridge) above 4GB.  However, the patch
> I have been playing with typedefs a phys_addr_t so that only
> systems which are 32-bit/36-bit+ split like PAE ia32, AUxxxx (MIPS),
> and PPC440 have to do long long manipulation.  If you explicitly
> use u64 everywhere it forces all native 32-bit/32-bit systems to
> do unnecessary long long manipulation.

Except for the fact that if you have a 32bit pci bus, you can
plug in cards with 64bit bars.  And they can still legitimately do
64bit DAC to other pci cards.  It is a silly configuration, but
possible.

Quote:> In the past there has been quite a bit of resistance to even
> introducing a physical address typedef due to some claims of
> gcc not handling long longs very well [1].  I don't see how
> having _everybody_ that is 32-bit native handle long longs is
> going to be more acceptable but I could be surprised.

The primary concern has been efficiency and I do believe there is
anywhere the pci resource allocator is on the fast path, so that
should not be a problem.

There are some rare bugs with 2.95.2 and kin with handling long longs
but all it has been possible to reformulate the C code so it works
in all cases where the bugs have been observed.

And beyond that it was Linus idea to bring the resource allocator to
64bits which tends to help.

Quote:> That said, I think when we have existence of systems that require
> long long types and gcc is "buggy" in this respect, then using
> a phys_addr_t is the lesser of two evils (even though everybody hates
> typedefs).  We already have this type defined local to PPC because
> it is necessary to cleanly handle ioremap and local page mapping
> functionality.  going to u64 or phys_addr_t resources would be a
> huge improvement on a horribly kludgy hack we use to crate the
> most significant 32-bits for our 64-bit ioremaps.

A phys_addr_t may be a sane idea, or in this case it would need to be
a res_addr_t.

Quote:> BTW, since u64 is long long on 32-bit platforms and long on 64-bit
> platforms, you will get warnings from every printk that dumps
> resource infos.  My thought is to provide some macros to massage
> resource values to strings for display.

> [1] I get feedback from many people using the PPC440 port and have
>     yet to find any instances of gcc mishandling long longs. (though
>     this is just anecdotal evidence).

I have written code that trips it up, but I believe the bugs have been
fixed in recent compilers, and the bugs (not the inefficiencies) may
be specific to a specific port.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

64-bit struct resource fields

Post by Eric W. Biederm » Tue, 03 Dec 2002 06:50:06



> We need some way to replicate the e820 tables for kexec.  This modifies struct
> resource to use u64's for its start and end fields. This way we can export the
> whole e820 table on PAE machines.

> resource->flags seems to be used often to mask out things in
> resource->start/end, so I think it needs to be u64 too.  

I don't see this in the parts of the kernel your patch changes, I will
have to look a little more and see if this is really true.  If it
is you probably should append ULL to the flag constants.

Quote:>But, Is it all right to

> let things like pcibios_update_resource() truncate the resource addresses like
> they do?

The type of addresses for resources will always be equal or larger
than the resources they actually represent.  Until someone modifies
the pcibios_xxxx code to handle 64bit BARs it should only be
truncation of zeros and thus safe.  

I will see if I can scrutinize this carefully, and try it in the next
little while.  For now I am placing it on the back burner and going
to bed.  It looks like a good start though.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

64-bit struct resource fields

Post by Matt Porte » Thu, 05 Dec 2002 20:30:27





> > > We need some way to replicate the e820 tables for kexec.  This
> > > modifies struct resource to use u64's for its start and end fields.
> > > This way we can export the whole e820 table on PAE machines.

> > > resource->flags seems to be used often to mask out things in
> > > resource->start/end, so I think it needs to be u64 too.  But, Is it
> > > all right to let things like pcibios_update_resource() truncate the
> > > resource addresses like they do?

> > > With my config, it has no more warnings than it did before.

> > I could make use of this on my PPC440 systems which have all I/O
> > (onboard and PCIX host bridge) above 4GB.  However, the patch
> > I have been playing with typedefs a phys_addr_t so that only
> > systems which are 32-bit/36-bit+ split like PAE ia32, AUxxxx (MIPS),
> > and PPC440 have to do long long manipulation.  If you explicitly
> > use u64 everywhere it forces all native 32-bit/32-bit systems to
> > do unnecessary long long manipulation.

> Except for the fact that if you have a 32bit pci bus, you can
> plug in cards with 64bit bars.  And they can still legitimately do
> 64bit DAC to other pci cards.  It is a silly configuration, but
> possible.

Erm, ok.  Silly is right, but possible.

- Show quoted text -

Quote:> > In the past there has been quite a bit of resistance to even
> > introducing a physical address typedef due to some claims of
> > gcc not handling long longs very well [1].  I don't see how
> > having _everybody_ that is 32-bit native handle long longs is
> > going to be more acceptable but I could be surprised.

> The primary concern has been efficiency and I do believe there is
> anywhere the pci resource allocator is on the fast path, so that
> should not be a problem.

> There are some rare bugs with 2.95.2 and kin with handling long longs
> but all it has been possible to reformulate the C code so it works
> in all cases where the bugs have been observed.

> And beyond that it was Linus idea to bring the resource allocator to
> 64bits which tends to help.

Ok, good.  Then that should include bringing all related interfaces
to 64bits as well?  Like remap_page_range(), since we want to handle
this easily on bigphys systems with I/O above 4GB instead of some of
our current hacks.

Quote:> > That said, I think when we have existence of systems that require
> > long long types and gcc is "buggy" in this respect, then using
> > a phys_addr_t is the lesser of two evils (even though everybody hates
> > typedefs).  We already have this type defined local to PPC because
> > it is necessary to cleanly handle ioremap and local page mapping
> > functionality.  going to u64 or phys_addr_t resources would be a
> > huge improvement on a horribly kludgy hack we use to crate the
> > most significant 32-bits for our 64-bit ioremaps.

> A phys_addr_t may be a sane idea, or in this case it would need to be
> a res_addr_t.

Sounds reasonable, I assume on some architectures that resources don't
map directly to physical addresses as DaveM once explained a resource
to merely be an ioremapable token (alpha?, sparc64?).  We'll need to
define a phys_addr_t to for the arguments to remap_page_range() but
this is a tangential to the original discussion...sounds like we need
both.

Quote:> I have written code that trips it up, but I believe the bugs have been
> fixed in recent compilers, and the bugs (not the inefficiencies) may
> be specific to a specific port.

Ok, the past discussions seemed to be implying the existence of horrible
bugs...sounds like gcc 3.x doesn't have these problems.  

Regards,
--
Matt Porter

This is Linux Country. On a quiet night, you can hear Windows reboot.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. 64-bit fields in struct net_device_stats

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello all,
        I was looking for a project that would take some time to finish, and I think
I found it - converting all code in the kernel to use u_int64_t (or similar)
instead of unsigned long in struct net_device_stats.
        Now, I have an idea on my mind about how to do this:

I'd move the structure to a new file in linux/include/asm
(linux/include/asm-{arch}/netdevice.h, for example) and implement there
couple of functions that would change the counters in the structure
(something like: static inline void net_stats_txbytes_add(struct
net_device_stats* stats, unsigned long len)). These would lock (if necessary
- - 32-bit architectures), add, unlock (if necessary.) The only thing is, that
all the NIC drivers in the kernel up to date would have to be changed to use
this new interface.

        Now, my question: Is there a better way of accomplishing this?

Thanks,
Jeff.

- --
A CRAY is the only computer that runs an endless loop in just 4 hours...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+7R3XwFP0+seVj/4RAolgAJ9QE4eLfKqrVhR9tktoZCHjcfarfgCcDb1A
HELhBfYleUbTSaTymmTsRJM=
=xu4t
-----END PGP SIGNATURE-----

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. Weird problem. Need HELP!!

3. HALstation (64-bit processor running 64-bit Solaris) as webserver

4. Recommendation on an Internal PCI modem

5. IBM announces 64-bit mainframes and 64-bit Linux for S/390

6. Problem booting LILO caused by Windows NT 3.5

7. 64-bit network statistics (struct net_device_stats)

8. u r trying to install on a machine which isnt supported by this release of red hat" ??

9. how do I insert 3 64-bit words into NUMBER field??

10. Is 64-bit Linux "true" 64 bit thru-and-thru??

11. 64 bit Unix (esp. 64 bit IO)

12. host mastered 64 bit wide transfers to 64 bit PCI slot?

13. performance of runing 32/64 bit program in 64 bit kernel.