tech-embed archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: compile vs run-time dependencies?



Garrett D'Amore wrote:
Perry E. Metzger wrote:

Garrett D'Amore <garrett%damore.org@localhost> 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





Home | Main Index | Thread Index | Old Index