On Sunday 19 September 2010, Greg McGary wrote: > > 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. We make a lot of changes everywhere in the kernel that directly benefit only a small subset of the community, like the RT work. I would think that the only important requirements are that your proposed changes do not become a burden for maintainance and that you minimise the risk for regressions. Having proper types for opaque scalars that can be used for both pointer and long values is a reasonable thing to do in general, and seems to fit that requirement. Right now, we use 'unsigned long' to mean a number of different things and from reading code it's not clear which one you want. Not sure of intptr_t is the best name, so we might come up with something better for this purpose, but it's a standard C99 type and the meaning is pretty much what we want anyway. Another possible alternative might be to add a kernel mode to your compiler that defines long as 64 bits, but with only 48 significant bits, like you have for your pointers. Does that work with your hardware? It seems that this would be fast and means fewer changes to the kernel, but opens a completely different can of worms in that it breaks code assuming that "ULONG_MAX == (1ul << (sizeof (unsigned long) * 8)) - 1", and might require many more changes to gcc. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
