Giuseppe Lettieri <giuseppe.letti...@unipi.it> writes: > Hi all, > > I have been thinking of the submodule suggestion and I have also > prepared a patch for it (attached). However, I am not sure about what > we want to achieve with it. In particular, I am not sure that the > option is useful for end users. The problem is that netmap, unlike > capstone and slirp, is a library plus a kernel module. If netmap is > not installed in the system, the --enable-netmap=git option will > successfully build qemu with netmap support, but then -netdev netmap > will fail at runtime.
Yes. What happens when I build with --enable-netmap=system on host A, then run the resulting binary on some host B that doesn't have netmap installed? > On the other end, if netmap is installed in the > system, using the =git option may cause qemu to be built against a > different, possibly incompatible version. Yes. We default to netmap=system, though. If you break things by passing arcane arguments to configure, you get to keep the pieces :) > If the option is only useful for developers to check that some qemu > change does not break anything, then probably it should be enabled in > some other, less visible way. What do you think? I think an --enable-netmap patterned after --enable-capstone and --enable-slirp has sufficiently low visibility as long as the default is sane. We clearly want configure to pick netmap=system when the system provides netmap. What shall configure pick when the system doesn't provide it? If you think netmap=git is too dangerous for general audience, consider disabling netmap then. Experts can still compile-test with --enable-netmap=git. Our CI certainly should.
