RE: [Linux-ia64] Re: [PATCH] head.S fix for unusual load addrs

From: Luck, Tony <>
Date: 2003-05-16 07:43:16
> It's a bit of "all of the above":
>  - The name isn't all that great, but since it _is_ doing something
>    rather strange, a strange names seems quite appropriate. The patch
>    should definitely add a brief (one-liner?)  explanation of what
>    __imva() stands for and what it does.  Also, I really dislike the
>    underscore silliness; let's just use ia64_imva() or some such, so
>    it's obvious that it is ia64-specific (there is no
>    namespace-pollution issue as there would be, say, in a user-level
>    library, so there is really no reason for using an underscore
>    prefix).
>  - the casting should be fixed
>  - instead of aspirins, it might be good to add the ASCII art you
>    posted recently in an appropriate place (either a header-file
>    or perhaps a Documentation/ia64 file); of course, the picture
>    you drew included text-replication, so we may want to hold off
>    with this until that part of the patch is in, too

Ok.  Here's a new patch (against a snapshot pulled from at about 9:30
this morning).  Builds and boots SMP on Tiger.

The __tpa() and __imva() macros are gone (along with their accursed
double underscore prefixes).

Types are cleaned up somewhat, there may be a couple of questionable
casts, but this looks to be as close to clean as I can make it.

The pre-existing ia64_tpa() function takes a __u64 argument, and returns
a __u64 value ... which matches nicely with all the uses in mca.c, setup.c
and smpboot.c which all use and return "unsigned long" (which is close
enough to __u64 that the compiler doesn't complain).

I've added a new function ia64_imva() which takes a "void *" argument and
returns a "void *" ... which matches with most of the uses, there are some
places that want an "unsigned long" return, so I still have some typecasts.
There's a two-line comment explaining what it does.

No ascii art in this patch, it isn't quite at head-ache complexity
yet.  But I'll definitely put some pictures in when we get to replication


Received on Thu May 15 14:44:08 2003

This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:14 EST