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. 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.
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.
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.
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.
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.
On Tuesday, January 07, 2014 03:57:22 AM Vladimir 'φ-coder/phcoder' Serbinenko wrote:
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
Again, just because you can't find a use for that option does not mean it should be removed.
Right now we're at opposite end when you almost have to use genetic algorithm to find which configuration works.
That's exactly why we have board-status. If you are using anything other than a pre-tested .config (and crossgcc), you are hacking, and that always comes with its associated set of risks. The fact that the majority of users are coreboot-impotent is not a reason to remove options.
Alex
P.S. Did I mention that linux has a billion times more options than we do?
-
mr.nuke.me＠gmail.com -
mrnuke
-
Vladimir 'φ-coder/phcoder' Serbinenko