> > I'm not a fan of binary plugins (for the same reasons I'm don't like > > binary kernel modules), and don't think there's any real need to them. > > A binary plugin API and a source plugin API (one that requires each driver > device to be recompiled for each of the platforms (Xen, qemu, bochs, etc.) > would probably be equally hard to design and maintain.
You've missed my point. The only reason I can see for wanting binary plugins is so that people can distribute proprietary closed-source device emulation. A stable source API is a prerequisite for any sort of binary plugins. > > I can't see > > any good reasons why open source devices would need to be broken out into > > a separate shared library. > > I think the case was already made for this. > > Xen's hardware emulation, while based on qemu's, is already ahead in > several aspects. A separate library would make it more convenient for these > changes to be shared back with qemu. Or with E/OS. I don't buy that. We either share the same drivers (in which case keeping the two in sync is trivial) or we don't. All of the systems under consideration are [L]GPL licences. We can easily copy the source, so I don't think being able to copy bits of binary goo gains us anything. I don't think executable size is a valid argument either. Device emulation code generally isn't that big so the overhead of breaking it up into multiple shared libraries would outweigh the benefits of not loading the bits you're not using. Paul _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
