[coreboot] [RFC] More generic targets with C preprocessor token concatenation

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Fri Feb 13 18:48:49 CET 2009

On 13.02.2009 17:19, ron minnich wrote:
> On Fri, Feb 13, 2009 at 4:30 AM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>> -struct mainboard_amd_dbm690t_config
>> +struct MAINBOARD_PREFIX##_config
> Here is the problem: now I don't know the name of that structure when
> I browse it; and, once again, this kind of trickery can trick me, but
> it is also unfriendly to source code analysis tools, which don't
> always pick these subtleties up. What happens with doxygen? What do
> the data structure graphs look like?

Point taken. I had assumed that kscope and doxygen would be able to
understand this.

> I realize this sort of thing is become more and more accepted in the
> GNU universe (just look at glibc!), so call me old-fashioned, but I
> feel a structure name should be a structure name, such that people
> don't need to indirect (i.e. grep) to go find out what it really is. I
> haven't found this kind of batch rename to be a huge issue,
> personally.

Since this was the first target I wanted to clone, I was surprised by
the amount of search and replace I had to do.

> I'm afraid I don't like the patch. :-)
> I'd like us to optimize, if anything, for code that is amenable to
> computer-assisted analysis. I was quite amazed to find out just how
> much (once again) e.g. glibc frustrates tools designed to analyze
> programs. We should be careful about going that route.

Can these programs deal with different structs definitions having the
same name, but living in different mainboard dirs?



More information about the coreboot mailing list