Garrett D'Amore wrote:
> Perry E. Metzger wrote:
> 
>> Garrett D'Amore <garrett@damore.org> writes:
>>  
>>
>>> From my perspective, there is little value in run-time checks for
>>> this, and frankly since a lot of the details can be handled by
>>> constant redefinitions in header files, compile-time checks will lead
>>> (I believe) to cleaner code.
>>>
>>> The drawback is that you need different kernels for different SoCs.
>>>   
>>
>>
>> There is nothing wrong with needing different kernels for different
>> boards. However, you should not try to evade the autoconf
>> machinery. It makes life a lot easier and more pleasant, and you'll be
>> happier using it than not using it. It is one thing to not bother
>> compiling in drivers that a board can't use and another to hard code
>> the locations for all the devices etc.
>>  
>>
> My idea is not to hard code the locations in the drivers per-se, but 
> rather to have compile time macros which might adjust the locations 
> appropriately.  Something like this:
> 
> #ifdef AU1550
> #define   USB_BASE   <someval>
> #else
> #define   USB_BASE   <someval>
> #endif
> 
> The other part that has to be compiled in is the interrupt routing (e.g. 
> for PCI).  I don't think there is any way to autodetect this, so it 
> winds up being surrounded in different #ifdef's, or built into 
> board-specific setup files.
> 
> The point is, different evaluation boards are going to need different 
> kernels.
> 
> And given that, having run-time selection for a bunch of options seems 
> silly.  It seems like it would be cleaner and quicker to use macros to 
> change the locations and IRQs, and to a certain extent this machinery 
> can be located in a single header file somewhere.
> 
>    -- Garrett

See sys/arch/mvmeppc/include/platform.h for one example of how to
solve the problem.  I did a proprietary port based on this, the same
kernel could run on two eval boards and the in-house design.  This can
save a lot of time during developer testing because you don't have to
rebuild, the next rev of your board won't require the customers to get
different firmware loads, and the resulting code ends up being an order
of magnitude cleaner than the ifdefs you're proposing.

-Neil