Re: [RFC][PATCH] Expanding the size of "start" and "end" field in "struct resource"

[Andrew Morton <akpm@osdl.org>]

ebiederm@xmission.com (Eric W. Biederman) wrote:
>
> Benjamin LaHaise <bcrl@kvack.org> writes:
> 
> > On Wed, Mar 15, 2006 at 02:29:32PM -0700, Eric W. Biederman wrote:
> >> If the impact is very slight or unmeasurable this means the option
> >> needs to fall under CONFIG_EMBEDDED, where you can change if
> >> every last bit of RAM counts but otherwise you won't care.
> >
> > But we have a data type that is correct for this usage: dma_addr_t.
> 
> Well the name is wrong.  Because these are in general not DMA addresses,
> but it may have the other desired properties.  So it may be
> useable.

Yes, dma_addr_t does the right thing but has the wrong name.

I guess it should have been called bus_addr_t (?).  If so, I guess a
suitable compromise might be:

#ifndef bus_addr_t
#define bus_addr_t dma_addr_t
#endif

then use bus_addr_t in struct resource.

Yes, we'd like to see the impact on vmlinux size, please.

Many of the problems will be in printks.  Whoever does this work should
capture stderr from before- and after- allmodconfig builds and diff them.

The appropriate way to printk a bus_addr_t will be

	printk("%lld", (unsigned long long)val);

which will increase code size even if bus_addr_t is u32, sadly.


Finally, we shouldn't just slavishly fix up great piles of printks to fix
the warnings (actually they're bugs).  Lots of the printks we have are
fairly useless, and there are other ways of finding out a device's IO and
IOMEM addresses anyway.

So IMO the preferred way of fixing a printk which is generating warnings is
to delete the thing.  Chances are that if the affected code actually has a
maintainer, he won't notice anyway ;)