[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Unified device model
From: |
Jim C. Brown |
Subject: |
Re: [Qemu-devel] Unified device model |
Date: |
Sun, 9 Apr 2006 12:08:22 -0400 |
User-agent: |
Mutt/1.4.2.1i |
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.
- Re: [Qemu-devel] Unified device model, (continued)
- Re: [Qemu-devel] Unified device model, Jim C. Brown, 2006/04/08
- RE: [Qemu-devel] Unified device model, Stanislav Shwartsman, 2006/04/09
- Re: [Qemu-devel] Unified device model, Paul Brook, 2006/04/09
- Re: [Qemu-devel] Unified device model, Jim C. Brown, 2006/04/09
- Re: [Qemu-devel] Unified device model, Paul Brook, 2006/04/09
- Re: [Qemu-devel] Unified device model, Sam Barnett-Cormack, 2006/04/09
- Re: [Qemu-devel] Unified device model,
Jim C. Brown <=
- RE: [Qemu-devel] Unified device model, Stanislav Shwartsman, 2006/04/09
- Re: [Qemu-devel] Unified device model, Fabrice Bellard, 2006/04/09
- Re: [Qemu-devel] Unified device model, Jim C. Brown, 2006/04/09
[Qemu-devel] Unified device model, pete sullivan, 2006/04/17
Re: [Qemu-devel] Unified device model, Einar Larsson, 2006/04/23