On Sun, Apr 09, 2006 at 04:21:42PM +0100, Paul Brook wrote: > > > 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.
I agree that proprietary or closed-source device emulation is a bad thing and should not be supported. > > A stable source API is a prerequisite for any sort of binary plugins. > In that case, perhaps a stable source API would be best. Like I said before, the type of API/sharing (source vs binary API, and static vs shared libraries) is a separate issue from the one we are discussing (should we have or support a unified plugin API?). > > > 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. A) Makes it simpler for end users to move devices over (they don't have to know how to cut-and-paste C code) B) Bochs is not related to qemu at all code-wise, so the cut-and-paste senario doesn't work here. If we want to share drivers with Bochs we'd need at least a source API. (The starter of this thread is a Bochs developer I believe... but correct me if I'm wrong here. :) The alternative is to rewrite Bochs drivers for qemu from scratch (possbly using the Bochs code as a guide) but that is even harder than the qemu-xen case. C) If they are in a special library (say maintained by a 3rd party group that consists of developers from all the major projects) then maintainance is greatly simplified over time. > > 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. Perhaps you are right about that. The size of having even 4 or 5 copies of complete PC hardware emulation code isn't so large as to be a problem except on systems that are either embedded or ancient (in which case you probably have no business running 4 different PC emulators anyways). Personally, it just seems inelegant to have such code duplication. > > Paul > -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
