[OpenAFS-devel] [PATCH 1/2] linux < 2.4 cleanup

[Jeffrey Hutzelman]

On Sunday, May 08, 2005 12:41:26 AM -0400 Derrick J Brashear 
<shadow@dementia.org> wrote:

> On Sat, 7 May 2005, Andres Salomon wrote:
>
>>> I agree.  We should try to keep the macros consistent.  Furthermore,
>>> __ia64__ and AFS_IA64_LINUX20_ENV have somewhat different meanings.
>>> One means (gcc && ia64), while the other means (linux && ia64).  I
>>
>> gcc, or something that emulates gcc, is a requirement for compiling the
>> Linux kernel.  I don't think there's any problem with including it in
>> the kernelspace portion of the openafs driver.  My patch was only going
>> to touched the LINUX specific directories, as it does mean (linux &&
>> ia64).
>
> That's still sort of crappy. Why not keep what we have, but look for ways
> to continue to move to ifdefs by function/action/feature instead of
> hardcoded by system?

I agree.  OpenAFS is not the Linux kernel, and it is not Linux-specific. 
Compiling OpenAFS does not require gcc.  I would prefer to have as few 
OS-specific and compiler-specific assumptions as possible.  Moving from 
using a macro which means exactly what we want it to mean and is defined 
exactly when we want it to be defined to one that means something different 
from what we are testing for and is defined depending on the whim of the 
compiler is _not_ an improvement.

As Derrick says, a move to feature-based macros rather than OS/platform 
based macros _would_ be an improvement, at least as long as such macros 
continue to mean exactly what we want them to mean and continue to be 
defined exactly when we want them to be defined.

-- Jeff