Re: [Qemu-devel] Unified device model

["Jim C. Brown" <jma5@umd.edu>]

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.