Re: Proposal: (u)intptr_t replaces (unsigned) long as opaque type

[Greg McGary <greg@mcgary.org>]

 On 09/18/10 21:06, Matthew Wilcox wrote:

> But it's only the beginnings of your problems.  There's so much userspace
> code that's written assuming ILP32 / LP64.  Even inside the kernel,
> people are going to constantly break your port by introducing new code
> that doesn't use uintptr_t.

Actually, the kernel is my final problem.  The userspace problem turned-out to
be quite manageable.  Within a year, working mostly alone, I have complete binutils,
GCC, uClibc, busybox and QEMU (Linux userland mode) ports running and I didn't even
come close to pulling-out my hair.  I have two-thirds of the SPEC2000 benchmarks
running correctly on QEMU, and I expect the remaining third to yield when I have
some time to debug them.  QEMU required the most surgery, and of the same kind as
Linux needs: s/target_long/target_intptr_t/ for vars that hold addresses.  uClibc
was also fast & loose in a few places regarding pointer/integer casts, but for the
most part, non-kernel code uses void* as the opaque type and char* or void* for
doing address arithmetic.  The kernel is the sloppiest of all regarding
pointer/integer casts.


I'm unconcerned about future breakage.  Over time, people will catch-on to the new
convention and breakage will diminish.  I'm much happier about fixing new problems
as they arise than about maintaining a port that is perpetually far from the mainline.


> Then there are other things we use unsigned long for, like interrupt
> status flags (spin_lock_irqsave and friends).  Should those be converted
> to some new type?

The only types that should be converted are for (a) opaque data that might hold
either a long or a pointer (e.g., ioctl arg, fcnt arg, generic callback function
args) and (b) data on which Linux does address arithmetic.  If an interrupt status
flag is not intended to hold an address, then there's no reason to change it.


> Essentially, you're asking us to take on a huge number of changes in
> order to make your new processor's performance not suck.  I don't think
> it likely you're going to find much sympathy here.

I propose this because (a) there is no impact on generated code for other ports,
and (b) it benefits code quality, flexibility, portability and self-documentation.
If the kernel is so ossified that avoiding changes has become the cardinal virtue,
then I guess I'm hosed.  8^)  As stated before, I'm prepared to submit changes
slowly over time in order to moderate the impact.

G