On Di, 2010-02-02 at 21:33 +0000, Lukas Zeller wrote: > If that's not sufficient, I'd propose extending the rule matching > mechanism itself according to the multiple-rule capabilities that are > already present: using <finalrule>no</finalrule>, the search for > matching rules can be continued, and options specified by the rules > will be accumulated. However only the last matching rule counts as the > "current" rule. This could be enhanced as follows: > > a) collect all rules that did match in a list, such that we can have > multiple "current" rules. > > b) add a <includerule> option for rules, such that a specific rule > (say: "7210c") could activate other more general rules (say: > "needsTZinVEVENT") which would also be added to the "current" rule > list. Things like that TZ could then be made depending on such a > general rule rather than the device rule itself. > > This would be reasonably easy to implement (I can do it if we agree > that this would be a useful solution) and would allow quite structured > rule trees without repeating common parts.
I think it would be useful to have and if you could implement this, we'd certainly appreciate the help. Conceptually it is similar to how I did compatibility hacks with CD writers: implement certain workarounds and make each of them depend on its own flag. Then when detecting a certain model, turn the right flags on. This worked well. In this case, the meta rules that don't match any particular device take the place of the flags. As an additional benefit, workarounds can be triggered both for such general "flags" as well as for specific models. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ os-libsynthesis mailing list [email protected] http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
