On Thu, Feb 28, 2008 at 3:40 PM, Carl-Daniel Hailfinger <<a href="mailto:c-d.hailfinger.devel.2006@gmx.net">c-d.hailfinger.devel.2006@gmx.net</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On 28.02.2008 21:22, Uwe Hermann wrote:<br>
> On Thu, Feb 28, 2008 at 06:18:04PM +0100, Carl-Daniel Hailfinger wrote:<br>
><br>
>> On 28.02.2008 12:52, Carl-Daniel Hailfinger wrote:<br>
>><br>
>>> On 28.02.2008 08:55, Corey Osgood wrote:<br>
>>><br>
>>>> Signed-off-by: Corey Osgood <<a href="mailto:corey.osgood@gmail.com">corey.osgood@gmail.com</a>><br>
>>>><br>
>>>><br>
>>> Signed-off-by: Carl-Daniel Hailfinger <<a href="mailto:c-d.hailfinger.devel.2006@gmx.net">c-d.hailfinger.devel.2006@gmx.net</a>><br>
>>><br>
>>> We may want to rewrite genfadt in a way where all constant members of<br>
>>> fadt are initialized at compile time instead of at run time. This<br>
>>> probably even decreases the size of the binary and improves speed at<br>
>>> run time.<br>
>>><br>
>> The more I look at the code, the less I believe the two tools with<br>
>> completely different purposes should be in one file. If you look at<br>
>><br>
><br>
> Maybe not one file (but I think it's fine too), but definately one<br>
> project/directory and one binary (which can be invoked with multiple<br>
> switches). Any ACPI-related functionality should we hack up should be<br>
> in one tool IMO.<br>
><br>
<br>
</div>One directory is OK with me. util/gen_acpi or something like that.<br>
However, the approach to have every possible acpi-related function in<br>
one binary is definitely a non-starter for me. Remember the Unix style<br>
of small tools doing small things? sed and grep are definitely related,<br>
but nobody (except maybe busybox folks) would argue to have them in one<br>
binary. In fact, sed and grep functionality is overlapping more than<br>
genfadt and gendsdt.<br>
Then again, having "stringtool --grep", "stringtool --sed" and<br>
"stringtool --cut" instead of grep, sed and cut would surely be fun.<br>
<div class="Ih2E3d"><br>
>> I hereby retract my signoff until we have discussed whether the merge<br>
>> makes sense for any reason besides disliking small utilities.<br>
>><br>
><br>
> It does IMO. Also, why should we keep them separate? There's no<br>
> advantage in doing that, it only needlessly increases the number of<br>
> small tools coreboot users are confronted with. Let's make it simpler<br>
> for users rather than more confusing.<br>
><br>
<br>
</div>See above. Plus, "gen_acpi --dsdt" is not simpler than "gendsdt". If you<br>
really want to make this conform to your definition of simple, merge<br>
genacpi and gendsdt into iasl and be happy. Maybe merge flashrom and<br>
superiotool as well. Or merge superiotool into dtc.<br>
<br>
Apologies for changing your argument from above, but it fits nicely:<br>
Also, why should we merge them together? There's no advantage in doing<br>
that, it only needlessly increases the number of command line switches<br>
<div class="Ih2E3d">coreboot users are confronted with. Let's make it simpler for users<br>
rather than more confusing.<br>
<br>
</div><div><div></div><div class="Wj3C7c">Regards,<br>
Carl-Daniel</div></div></blockquote><div><br>This was how I'd envisioned it:<br>genacpi - make both tables, with hardcoded paths<br>genacpi -d/--dsdt [INFILE] [OUTFILE] - make the dsdt, with optional parameters<br>fadt works the same way.<br>
<br>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.<br>
<br>-Corey<br></div></div>