[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?


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/





More information about the coreboot mailing list