Brice Goglin, le Tue 25 Sep 2012 09:27:23 +0200, a écrit : > On most OS, we already have multiple "core os" components, one native > (linux, ...) with priority 10 and the "noos" one with priority 0. If > nothing forces a specific component in the list (no env variable, no > set_xml, ...), we instantiate the first one (higher priority), which is > the native component when it exists. > > Everything is "loaded" and added to some list. Only one is enabled in > the core os list. All are enabled in the additional list (except if some > flag in the core os component disables things, that's what XML/synthetic > do to disable PCI). > > pci (additional list) is always loaded, and it gets enabled except if > XML/synthetic set a flag. > > linuxx86 (os list) only gets enabled if first in the list (priority) or > an env var forces it.
Well, I guess all of this should go into the documentation, otherwise it's difficult to get an idea of what plugin gets loaded. 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. > > Also, I guess that we probably want that some plugins be enabled by > > default if they are found (because they add useful information but > > depend on an external dep), and that some others are not enabled by > > default (because they add information, but e.g. to the expense of > > computation time, due to e.g. measurements etc.). > > We have no way to force disable one specific additional component. > Could be a "expensive" flag or "cost" in the component struct with a env > var. "expensive" was just an example of what makes loading it by default a bad idea. We can't invent a thorough list of such things, so I'd say plugins could rather just enable a "default_load" flag or not. > And a syntax such as pci,^servet to select manually. Why a ^? > > It could also be to use another PCI detection plugin that libpci. > > Ok, two good reason to let us change the list the additional components. > Do we want to specifiy the "core OS" component and the "core additional" > list in the same env var? It would make it clear that they are different things, but see below. > There's currently no way to prevent two PCI backends to be used > simultaneously. Might use another flag so that only the first one > (libpci) or a specific one (env var) is enabled. Well, perhaps we should rather define well-known names which act as exclusion points and document them. I.e. what is currently called "core os" should perhaps actually be an "os" exclusion point, while core_libpci would use the "pci" exclusion point, and another pci detection plugin would use the same exclusion point. Priorities can then be used among plugins of the same exclusion point to sort out which one should be used. Actually, the current core os plugins should perhaps be split into a "bind" exclusion point and a "cpu" exclusion point. One issue I had with linuxx86 is that I need the part that provides binding functions, but not the part which provides the cpu detection. And it will be the same in other OSes. Also, loading another plugin for "bind" operations can make sense. Samuel
