Re: PATCH 2.3.23.5: physical address typedef

Jamie Lokier (lkd@tantalophile.demon.co.uk)
Fri, 22 Oct 1999 15:48:40 +0200


Jes Sorensen wrote:
> The term 'physaddr' referring to things to be
> used with ioremap() is just bogus, ioremap takes a bus address not a
> physical one.

Quite. It should be `busaddr_t'. `physaddr_t' should be reserved for
physical addresses that only the mm layer sees...

> Type typedef's are a pain when there is no real reason for them,
> ie. for atomic types and spin locks there is a good reason, for simple
> pointers there aren't.

A bus address is not a pointer...

> Addind yet another random typedef just makes the code even more
> obfuscated. You will be able to do just as much damage with this new
> type as you can do with unsigned long's.

Obfuscation? If it's made mandatory right away I agree. If it's the
wrong name, I agree. (kphysaddr_t is the wrong name). If it has the
wrong semantics: i.e., it doesn't always hold a bus address, I agree.
But if it does have a consistent meaning how can you call it
obfuscation?

Bear in mind that unsigned long is the *wrong* type (on x86 with 64-bit
PCI), though that hasn't arrived yet. And char * is also the wrong
type.

> Basic rule is that you need to know what you are doing anyway.

This is clearly not true: we have device drivers that _ought_ to work on
many architectures but don't because they make assumptions they
shouldn't. This doesn't stop the drivers getting written and used for a
long time, and that makes changes to the core architecture, as well as
porting, difficult.

I favour not only the typedefs, but structs for catching mis-typing when
enough drivers have been cleaned up (as with ptes at one time).

-- Jamie

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