Re: [PATCH] 64-bit struct resource fields

[Matt Porter]

On Sun, Dec 01, 2002 at 09:26:03PM -0700, Eric W. Biederman wrote:
> Matt Porter <[e-mail]> writes:
> 
> > On Mon, Nov 25, 2002 at 03:11:00PM -0800, Dave Hansen wrote:
> > > 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.
  
> > 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.
 
> > 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.

> 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
[e-mail]
This is Linux Country. On a quiet night, you can hear Windows reboot.