Jamie> Jes Sorensen wrote:
>> 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.
Jamie> A bus address is not a pointer...
Of course it is, it points to a bus area - that doesn't mean it is
valid to access it directly.
>> 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.
Jamie> Obfuscation? If it's made mandatory right away I agree. If
Jamie> it's the wrong name, I agree. (kphysaddr_t is the wrong name).
Jamie> If it has the wrong semantics: i.e., it doesn't always hold a
Jamie> bus address, I agree. But if it does have a consistent meaning
Jamie> how can you call it obfuscation?
Because we are then adding typedef's for random things for little
reason. Whether a pointer is a bus address typedef or an unsigned long
makes little different, buggy code can still put whatever broken
address into it.
Jamie> Bear in mind that unsigned long is the *wrong* type (on x86
Jamie> with 64-bit PCI), though that hasn't arrived yet. And char *
Jamie> is also the wrong type.
32 bit PCI does dual address cycles, it's not just wrong on 64 bit
PCI. Besides that then you are implicitly stating that a bus address
== PCI bus address.
>> Basic rule is that you need to know what you are doing anyway.
Jamie> This is clearly not true: we have device drivers that _ought_
Jamie> to work on many architectures but don't because they make
Jamie> assumptions they shouldn't.
Most of this is due to the fact that many programmers expect all
architectures to work like the x86. The bus address handling is the
least of the problem here.
Jamie> I favour not only the typedefs, but structs for catching
Jamie> mis-typing when enough drivers have been cleaned up (as with
Jamie> ptes at one time).
BARF, in English that is also called "make life painful for the people
who writes the code for the sake of making life painful"
Jes
PS: Oh and your mail client is broken, it eats the References: lines
which is really annoying.
-
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/