[coreboot] GENFADT and GENDSDT

[Carl-Daniel Hailfinger]

On 29.02.2008 06:23, Corey Osgood wrote:
> On Thu, Feb 28, 2008 at 3:40 PM, Carl-Daniel Hailfinger <
> c-d.hailfinger.devel.2006 at gmx.net> wrote:
>
>   
>> On 28.02.2008 21:22, Uwe Hermann wrote:
>>     
>>> On Thu, Feb 28, 2008 at 06:18:04PM +0100, Carl-Daniel Hailfinger wrote:
>>>
>>>       
>> One directory is OK with me. util/gen_acpi or something like that.
>> However, the approach to have every possible acpi-related function in
>> one binary is definitely a non-starter for me. Remember the Unix style
>> of small tools doing small things? sed and grep are definitely related,
>> but nobody (except maybe busybox folks) would argue to have them in one
>> binary. In fact, sed and grep functionality is overlapping more than
>> genfadt and gendsdt.
>> Then again, having "stringtool --grep", "stringtool --sed" and
>> "stringtool --cut" instead of grep, sed and cut would surely be fun.
>>
>>     
>>>> I hereby retract my signoff until we have discussed whether the merge
>>>> makes sense for any reason besides disliking small utilities.
>>>>
>>>>         
>>> It does IMO. Also, why should we keep them separate? There's no
>>> advantage in doing that, it only needlessly increases the number of
>>> small tools coreboot users are confronted with. Let's make it simpler
>>> for users rather than more confusing.
>>>
>>>       
>> See above. Plus, "gen_acpi --dsdt" is not simpler than "gendsdt". If you
>> really want to make this conform to your definition of simple, merge
>> genacpi and gendsdt into iasl and be happy. Maybe merge flashrom and
>> superiotool as well. Or merge superiotool into dtc.
>>
>> Apologies for changing your argument from above, but it fits nicely:
>> Also, why should we merge them together? There's no advantage in doing
>> that, it only needlessly increases the number of command line switches
>> coreboot users are confronted with. Let's make it simpler for users
>> rather than more confusing.
>>
>>     
> This was how I'd envisioned it:
> genacpi - make both tables, with hardcoded paths
> genacpi -d/--dsdt [INFILE] [OUTFILE] - make the dsdt, with optional
> parameters
> fadt works the same way.
>   

Can we at least agree on the name of the directory where the tool(s) 
should live? Should we call it gen_acpi or genacpi? I'd say you decide 
on the name, add a signoff to the act of directory creation and I'll ack 
and commit (the directory creation). That will allow us to pull the 
directory into v2 and v3 with svn:externals and we at least have the 
infrastructure in place.

> Call me crazy, but I'd be willing to be 90% of coreboot users, especially
> non-developers, just want both tables in one simple step, that's why that's
> what I focused on. Most of the advanced users will probably still use iasl
> anyways, since gendsdt/fadt/acpi provides absolutely NO optimizations (read:
> bigger) nor does it do any checking of whether or not the ACPI tables it
> creates are anywhere near valid.
>   

Please note that iasl can't perform any of the functions of 
gendsdt/genfadt and vice versa. The inner workings of genfadt also 
differ from those of gendsdt: gendsdt just creates a file containing a 
char array with the AML DSDT (and we probably should rename it to 
embed_dsdt or include_dsdt), while genfadt generates code modifying the 
FADT at runtime.
If you really want to have genfadt and gendsdt in one binary, let's at 
least keep the source files separate. And there's one really interesting 
question: How should we integrate the tool Rudulf is writing at the 
moment? His tool generates the powernow part of the DSDT, but it outputs 
ASL, not a char array containing AML.

Regards,
Carl-Daniel

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