> Now let's examine how QEMU machine configuration and FDT machine > descriptions for kernels are related. > > In a way, both can be regarded as copies of a complete machine > description with lots of stuff pruned. Except the complete machine > description doesn't exist. Because there is no use for it. > > FDT routinely prunes stuff like PCI and USB devices, because those are > better probed. > > QEMU configuration should certainly prune everything that is not > actually configurable.
I'm not sure I agree here, or at least we may be talking past each other. IMHO the machine config should specify all the bits of the machine that don't really want to be exposed to the average user. e.g. the memory layout and interrupt routings, etc. We then have a seaparate user config file (possibly structured differently) which exposes things like host bindings for disks and network devices. It's all a bit muddy because the current commandline options effect both the devices present and the host bindings for the corresponding interfaces. While this seems like a good idea to start with, I'm not convinced this is actually a desirable feature. Certainly for embedded machines you want a fixed set of hardware. e.g. if we have a SoC with 3 UARTs we should always create those 3 devices, and it's not meaningful to have more. If the user doesn't specify sufficient -serial options then the remainder just get connected to /dev/null. Likewise there's a good argument for having the vlan and disc configuration be separate from creation of the NIC/HBA devices. One possibility is that it might actually make more sense to specify hot-pluggable devices (e.g. PCI and USB) in a sumilar way that they would be added at runtime, rather than trying to force them into a static tree. My implementation focsed on just the machine config, mostly ignoring the user config and host bindings. Paul _______________________________________________ devicetree-discuss mailing list [email protected] https://ozlabs.org/mailman/listinfo/devicetree-discuss
