From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Unified device model
Date: Sun, 9 Apr 2006 16:21:42 +0100 [thread overview]
Message-ID: <200604091621.45594.paul@codesourcery.com> (raw)
In-Reply-To: <20060409145555.GA5081@jbrown.mylinuxbox.org>
> > 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
next prev parent reply other threads:[~2006-04-09 15:21 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-08 19:57 [Qemu-devel] Unified device model Stanislav Shwartsman
2006-04-08 19:12 ` Jim C. Brown
2006-04-08 19:17 ` Johannes Schindelin
2006-04-08 19:27 ` Leonardo E. Reiter
2006-04-09 6:29 ` Stanislav Shwartsman
2006-04-08 19:28 ` Jim C. Brown
2006-04-09 6:26 ` Stanislav Shwartsman
2006-04-09 10:38 ` Paul Brook
2006-04-09 14:55 ` Jim C. Brown
2006-04-09 15:21 ` Paul Brook [this message]
2006-04-09 15:28 ` Sam Barnett-Cormack
2006-04-09 16:08 ` Jim C. Brown
2006-04-09 19:56 ` Stanislav Shwartsman
2006-04-09 21:02 ` Fabrice Bellard
2006-04-09 15:10 ` Jim C. Brown
[not found] <1b33de610604170003q43b6c453ub94d77b1a10ed43b@mail.gmail.com>
2006-04-17 7:09 ` pete sullivan
-- strict thread matches above, loose matches on Subject: below --
2006-04-23 21:03 Einar Larsson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200604091621.45594.paul@codesourcery.com \
--to=paul@codesourcery.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).