Re: [PATCH 1 of 3] add phys_addr_t for holding physical addresses

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Benjamin Herrenschmidt
Date: Sunday, August 24, 2008 - 2:39 am

.../...

 
 .../...

Might sound a stupid question, but why have a CONFIG_ option and
a global definition based on it rather than each arch defining it
as part of the base types ? I don't have a firm preference for one
or the other at this point, I can see pro and cons to both approach,
so I'm curious to see what others think about it.

Cheers,
Ben.


--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[PATCH 0 of 3] define and use phys_addr_t, Jeremy Fitzhardinge, (Tue Aug 19, 1:02 pm)
[PATCH 1 of 3] add phys_addr_t for holding physical addresses, Jeremy Fitzhardinge, (Tue Aug 19, 1:02 pm)
[PATCH 2 of 3] make PFN_PHYS explicitly return phys_addr_t, Jeremy Fitzhardinge, (Tue Aug 19, 1:02 pm)
[PATCH 3 of 3] redefine resource_size_t as phys_addr_t, Jeremy Fitzhardinge, (Tue Aug 19, 1:02 pm)
Re: [PATCH 1 of 3] add phys_addr_t for holding physical ad ..., Jeremy Fitzhardinge, (Fri Aug 22, 2:11 pm)
Re: [PATCH 1 of 3] add phys_addr_t for holding physical ad ..., Jeremy Fitzhardinge, (Fri Aug 22, 3:30 pm)
Re: [PATCH 1 of 3] add phys_addr_t for holding physical ad ..., Benjamin Herrenschmidt, (Sun Aug 24, 2:39 am)
Re: [PATCH 1 of 3] add phys_addr_t for holding physical ad ..., Jeremy Fitzhardinge, (Sun Aug 24, 9:59 am)