On Sun, Oct 6, 2013 at 8:54 PM, Theodore Ts'o <tytso@xxxxxxx> wrote: > On Mon, Oct 07, 2013 at 02:27:04AM +0100, Matthew Garrett wrote: >> > > Having a per-entry comment is significantly clearer. >> > >> > That is your opinion, it's not a demonstrable fact. >> >> Say one of the machines turns out to need the quirk for two different >> reasons. How do we document that? Look, how about you add the comments >> and I'll do a patch that adds documentation to the existing entries? I'm >> not asking you to make up for other people's past mistakes, I'm asking >> you not to perpetuate them. > > Felipe, > > I have to agree with Matthew here. Lists have a way of getting messed > up. If not in the upstream kernel, can we be sure that none of the > distribution maintainers might not respect the ordering? That would be a problem for the distribution maintainers, wouldn't it? And regardless of how we document the list, they can still mess it up. > How about doing something like this: > > /* > * [1] Busted brightness controls > * [2] Attempted compatibility with ancient enterprise Linux kernel causes > * 20% performance regression on upstream kernels > * [3] Disables video card functionaity to be bug-for-bug compatible with > * Windows after attempted hobbling in the propietary driver > * was wored around, etc. > * etc. > */ > > Then individual entries can be annotated with comments indicating > [1][2], etc. That would be better than Matthew's proposal, but it would make the code less readable, for the same reason spaghetti code is not readable (you have to jump back and forth to understand what's going on). > That way, if someone clever decides that they want to alphabetize the > entries, or we have so many exceptions due to incompetent BIOS > programmers, and some future developers decides that he or she needs > to implement a binary search to speedup lookups, or some such, we > won't need to worry about ordering-specific semantics getting smashed. How about we worry about hypothetical issues when they arise? (which is probably going to be never). Personally I think this is more than enough: http://article.gmane.org/gmane.linux.acpi.devel/64243 -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
