On Thu, Feb 28, 2008 at 3:40 PM, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@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:
>
>> On 28.02.2008 12:52, Carl-Daniel Hailfinger wrote:
>>
>>> On 28.02.2008 08:55, Corey Osgood wrote:
>>>
>>>> Signed-off-by: Corey Osgood <corey.osgood@gmail.com>
>>>>
>>>>
>>> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
>>>
>>> We may want to rewrite genfadt in a way where all constant members of
>>> fadt are initialized at compile time instead of at run time. This
>>> probably even decreases the size of the binary and improves speed at
>>> run time.
>>>
>> The more I look at the code, the less I believe the two tools with
>> completely different purposes should be in one file. If you look at
>>
>
> Maybe not one file (but I think it's fine too), but definately one
> project/directory and one binary (which can be invoked with multiple
> switches). Any ACPI-related functionality should we hack up should be
> in one tool IMO.
>

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.

Regards,
Carl-Daniel

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.

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.

-Corey