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