Le 25/09/2012 10:48, Samuel Thibault a écrit : > Le 25/09/2012 09:49, Samuel Thibault a écrit : >>> One thing which can be confusing for the user is that core_linux goes >>> to the core os list while core_libpci goes to the additional list. It >>> would probably be better to use a different class name. I actually don't >>> currently understand what classes are used for. >> The class name was initially used to distinguish between normal (core) >> plugins and xml backends. It may be possible to completely remove it now >> that component struct have a type, I'll check. > Ok. I was also hit by the fact that core_linux_x86 is not valid, only > one '_' is allowed.
Right, this check doesn't make much sense anymore. I am removing it. >> We have the "core_xml" component (generic xml support) and "xml_libxml" >> + "xml_nolibxml" backends behind that. I am fine with removing the >> "core_" prefix, but I wonder if we should keep the "xml_" prefix for the >> latter. > I'd say we should keep it. Just like I wanted to use core_linux_x86 (as > opposed to core_linux) Keep which one? "core" or "core" and "xml" ? > Well, that still looks hardcoded to me. Actually, a simple way would > be to order all plugins in just one list by priorities. When loading a > plugin, one checks whether the exclusion point of the plugin was > already filled or not, and load the plugin accordingly The good thing about this is that XML and synthetic can set exclusion flags on OS+PCI+ADDITIONAL. But we obviously don't want cuda, ... to set the ADDITIONAL exclusion flag. So setting a exclusion flag would mean "I don't want any plugin of this type to be enabled" (different from "I don't want any plugin with this exclusion flag to be set). >> We should hide xml backends/plugins as much as possible in the doc, we >> have old env variables to deal with those, no need to tell people that >> the way it works changed internally. > You are talking about xml only, not other plugins, right? Well, I > believe it still makes sense to expose the xml ones as loadable just > like the linuxx86 plugin is, or even a user-provided plugin. Yes only talking about XML. Brice