Subject: Re: compile vs run-time dependencies?
To: Perry E. Metzger <perry@piermont.com>
From: Garrett D'Amore <garrett_damore@tadpole.com>
List: tech-embed
Date: 10/16/2005 11:40:08
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