On Do, 2017-03-16 at 11:46 +0200, Janne Huttunen wrote: > On Wed, 2017-03-15 at 08:24 +0100, Gerd Hoffmann wrote: > > > > > > The short answer: emulating real hardware. > > > > Ok, that is reason enough. > > > > Adding bootonceindex everywhere doesn't look like the best plan to me > > though. Possibly we can pimp up bootindex in a backward-compatible > > way? > > Something like bootindex=<normal>[.<once>] ? > > That would (likely) avoid modifying all devices, but wouldn't > that make the 'bootindex' property a string (now: 'int32') > and thus change the QOM API?
Good point. I was thinking about the cmd line only where it is a string anyway. > I did consider making device_add_bootindex_property() to > automatically add the new property too, but since that API > is currently such that the _caller_ provides the name of the > added property, it would mean that the function would need > to generate the second name using some magic mangling rule > and that didn't seem very nice to me. I think the only case where this is something != "bootindex" is the floppy controller, which has bootindexA and bootindexB for the two drives. So name mangling doesn't look too bad to me. Maybe we could just add a "first-" or "once-" prefix. But the second bootindex still needs to be stored somewhere in the device state struct ... > Of course the API could > be modified so that the caller provides two names, but then > we are already back to modifying all relevant devices. ... so I guess there isn't really some way around that. cheers, Gerd
