[coreboot] GENFADT and GENDSDT
corey.osgood at gmail.com
Fri Feb 29 06:23:42 CET 2008
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:
> >> 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 at gmail.com>
> >>> Signed-off-by: Carl-Daniel Hailfinger <
> c-d.hailfinger.devel.2006 at 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.
This was how I'd envisioned it:
genacpi - make both tables, with hardcoded paths
genacpi -d/--dsdt [INFILE] [OUTFILE] - make the dsdt, with optional
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the coreboot