Paul Brook wrote: >> the "class" field is used to select the device model. Then all the other >> parameters are used to initialize the device model. That way it is >> possible to keep the compatibility with the existing options and add a >> provision to instanciate arbitrary new device models, such as: >> > > I like the idea, but I'm not so keen on the automatic allocation. I generally > prefer explicit declaration over implicit things. The latter makes it very > easy to not notice when you make a typo. > > It sounds like what you really want is something similar to an OF device > tree. > So you have something like: > > # pciide0 may be an alias (possibly provided by qemu) > # e.g. pci0.slot1.func1.ide > alias hda ide0.primary.master >
What I don't like about the ide0.primary.master syntax is that there isn't enough structure. I would prefer: alias hda ide,bus=0,primary,master If you combine this with your magic variable idea, you could also do: alias hda ide,bus=0,unit=$next But you could also just fold that into Fabrice's syntax (which I prefer): hda.class = ide,bus=0,unit=$next hda.type = disk hda.file = foo.img If you then default bus, and unit, you can just write: hda.class = ide hda.type = disk hda.file = foo.img And better yet, you could even allow for something like: hda.class = ide hda.bus = 0 hda.unit = 0 hda.type = disk hda.file = foo.img So I really actually prefer Fabrice's syntax because there is much more structure. I think it's a good idea to allow .class to contain multiple properties and to basically establish an alias. This way, you could predefine a bunch of aliases for today's parameters like hda, hdb, etc. > hda.type=disk > hda.file=foo.img > > You can then define some form of magic aliases that select the next unused > device. e.g. > > alias mydrive $next_ide_disk > > IMHO This provides the flexibility and structure that Fabrice is talking > about, and with suitable aliases can be made to look a lot like the existing > options. > > This may require some internal restructuring to allow the machine > descriptions > to feed into the user config file. > I think if we choose a syntax we like, we can start using that pretty easily. We'll have to start adjusting option names keeping them only valid on the command line (for things like -m). However, I think it would grow pretty well into a machine description mechanism. Regards, Anthony Liguori > Thoughts? > > Paul > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
