Peter Maydell <peter.mayd...@linaro.org> writes: > On 15 December 2013 20:55, Andreas Färber <afaer...@suse.de> wrote: >> Since you're mentioned by name, should I wait for you to review the >> three OMAP parts? > > There's nothing particularly omap-specific in them.
The only OMAP-specific issue I can think of would be me misreading the intent of the code. > I kind of think this whole thing is backwards anyway: > we should really say "the user can only instantiate > devices via command line or monitor that are specifically > intended to be hot-pluggable", rather than having an > enormous list of devices we flag as not instantiable > by the user. Even if someday we manage to make it technically > possible to instantiate an omap_i2c device (say) from the > command line, it will still be a completely bizarre thing to do > because it's only intended to work as a part of the omap SoC. "Hot-pluggable" doesn't apply here. There are plenty of devices that can only be cold-plugged, yet are absolutely meant to be user-pluggable. Real ISA cards, for instance. I share your doubts on the wisdom of letting users plug components via command line or monitor that are really just parts of bigger components, like the OMAP SoC. However, the current code lets users plug absolutely everything, even stuff that is known not to work. The code still has the remnants of a mechanism meant to protect users from known-not-to-work plugs, but it got broken some time ago. My "Clean up and fix no_user" series fixes that regression in a way that's hopefully agreeable with Anthony, who has been quite insistent on letting device_add plug more rather than less. This series merely patches some holes on top. The list of non-pluggable devices may be larger than the list of pluggable ones, but: I count just 48 instances of "cannot_instantiate_with_device_add_yet = true". I doubt marking devices that can be plugged instead of the ones than can't be would take fewer marks. Moreover, each one comes with a comment explaining *why* the device cannot be plugged. Sure nice to have when such a "why" goes away. Some of them are expected to go away eventually. > Being able to write board models in something other than C > would be nice, but I really think that if we pursue the idea of > being able to do it all on the command line we'll just end up with > a horrifically confusing command line syntax. Command line / monitor could be divorced from hardware configuration. Doesn't make much sense with the rather primitive device_add we got now. May well make sense when our means to wire up hardware by configuration rather than code have moved closer to the complex wirings we need to model.
