On 07.01.2014 00:12, mrnuke wrote: > On Monday, January 06, 2014 07:52:20 PM Vladimir 'φ-coder/phcoder' Serbinenko > wrote: >> By now most boards and OS don't run correctly if ACPI tables are not >> supplied. Ability by user to enable/disable their generation is just >> increasing configuration matrix for no benefit. So I propose to hardwire >> it to HAVE_ACPI_TABLES. > > You mean you haven't found a need for it in your recent use cases. I don't > think this can be used to generalize for all boards, and is most certainly a > naive proposal for ARM boards. So you end up depending this shit on ARCH_x86, > then ARM adds ACPI, then it again makes sense to HAVE_ACPI_TABLES, but only > for ARM, so now we make it depend on ARCH_ARM, and we get a clusterfuck by > the > end of the day. > At the end of it all, you are proposing to take away a freedom that has hurt > no-one. -2. I can't see the justification. > You misunderstood. I don't propose to remove HAVE_ACPI_TABLES. HAVE_ACPI_TABLES remains per-board characteristic. The only thing I remove is GENERATE_ACPI_TABLES which is user-visible option. This way presence of ACPI-tables is determined by board porter based on the need and availability of ACPI tables >> I feel like in current config there are too many options of kind "Do you >> want a working system? (y/n)" and they should be hardwired to right >> answer rather than adding configuration. >> > Flashing coreboot is a minefield of these questions: "Do you want to brick > your > system? (ok/cancel)". You can't make it fool proof, and nanny-state-ing users > is not the solution. Provide sane defaults. > Right now we're at opposite end when you almost have to use genetic algorithm to find which configuration works. > Alex > > P.S. If you don't know what you're doing, you will brick your board, no > matter > how many coreboot condoms you wear. >
signature.asc
Description: OpenPGP digital signature
-- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
