On Tue, Apr 29, 2025 at 11:20:59AM +0200, Thomas Huth via Devel wrote: > On 29/04/2025 10.23, Markus Armbruster wrote: > ... > > I don't wish to derail this thread, but we've been dancing around the > > question of how to best fix the target for some time. I think we should > > talk about it for real. > > > > Mind, this is not an objection to your larger "single binary" idea. It > > could be only if it was an intractable problem, but I don't think it is. > > > > You want the single binary you're trying to create to be a drop-in > > replacement for per-target binaries. > > > > "Drop-in replacement" means existing usage continues to work. > > Additional interfaces are not a problem. > > > > To achieve "drop-in replacement", the target needs to be fixed > > automatically, and before the management application can further > > interact with it. > > > > If I understand you correctly, you're proposing to use argv[0] for that, > > roughly like this: assume it's qemu-system-<target>, extract <target> > > first thing in main(), done. > > > > What if it's not named that way? If I understand you correctly, you're > > proposing to fall back to a compiled-in default target. > > > > I don't think this is going to fly. > > I tend to disagree. For normal users that consume QEMU via the distros, the > check via argv[0] should be good enough. For developers, I think we can > assume that they are adaptive enough to use an additional "-target" option > in case they mis-named their binary in a bad way.
> > Developers rename the binary all the time, and expect this not to change > > behavior. For instance, I routinely rename qemu-FOO to qemu-FOO.old or > > qemu-FOO.COMMIT-HASH to let me compare behavior easily. > > Developers should already be aware that this can cause trouble, since e.g. > the qtests are deriving the target architecture from the binary name > already. See the qtest_get_arch() function. Even if we want to allow developers to rename binaries, we don't have to allow an arbitrary choice of naming. We could define an accepted pattern for naming that people must follow. eg we could allow for clearly distinguished suffixes (ie append '-SUFFIX') so that qemu-system-x86_64-fishfood is acceptable while qemu-system-fishfood qemu-system-x86_64fishfood would be an unsupported scenarios. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
