qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gianni Tedesco <gianni@scaramanga.co.uk>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] plugins
Date: Fri, 09 Jul 2004 14:48:48 +0100	[thread overview]
Message-ID: <1089380928.3101.21.camel@sherbert> (raw)
In-Reply-To: <40EE9F13.405@fabianowski.de>

[-- Attachment #1: Type: text/plain, Size: 2308 bytes --]

On Fri, 2004-07-09 at 15:35 +0200, Bartosz Fabianowski wrote:
> > With a plugin system (all it takes is 2 files: an text/XML file which 
> > contains the info on this plugin, and a .so file which is the plugin
> 
> Binary plugins, especially closed source ones, always create the problem 
> of binary compatibility. QEMU's 0.5 version number already indicates 
> that although it works very well already, it is nowhere near finished. 
> Features change very quickly in CVS, just think about how pci was an 
> experimental option a short while back and now it's the default.

Adding PCI could easily have been binary backwards compatible. Anyway,
we're not talking about necissarily having a stable or backwards
compatible ABI, just an API which makes developing new code simpler and
makes each module more flexible. It doesn't have to be there to
encourage out-of-tree development at all.

> I think 
> it would be really hard to come up with an API that would remain stable 
> for multiple releases at this point. Also, the need to maintain 
> backwards compatibility would hamper QEMU's development. And finally, 
> creating and maintaining an API would drain lots of resources from QEMU 
> development while benefiting only very few people who want to distribute 
> closed source plugins.

No developing and maintaining a stable or backwards compatible ABI would
do that. An API that doesn't have to be stable or backwards compatible
won't.

> Maybe at a much later stage, when QEMU is stable 
> and mature, binary plugins will make sense. But for now, it seems like 
> the source code extensibility QEMU offers is good enough.

No, I think plugins should be built from the main qemu source and
external developers would ideally release new plugins as source
distributions to compile against your qemu core. Anything else requires
maintaining an ABI.

Another benefit of DSO based plugins is saving memory and virtual
address space, only loading the plugins which are required. It would
also save on disk space as common code can be shared amongst the various
qemu targets.

-- 
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2004-07-09 13:51 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-08 18:14 [Qemu-devel] RFC for new features Fabrice Bellard
2004-07-08 18:46 ` [Qemu-devel] " Emmanuel Charpentier
2004-07-08 18:58   ` Antony T Curtis
2004-07-08 19:05   ` Julian Seward
2004-07-08 19:47   ` Jim C. Brown
2004-07-08 18:54 ` [Qemu-devel] " Antony T Curtis
2004-07-08 19:36   ` Jim C. Brown
2004-07-08 20:31     ` Jernej Simončič
2004-07-08 21:04       ` Jim C. Brown
2004-07-08 22:37         ` Jernej Simončič
2004-07-08 22:57           ` Jim C. Brown
2004-07-09  0:15           ` [Qemu-devel] RFC for new features (Console under Windows) Filip Navara
2004-07-08 23:40         ` OT: Re: [Qemu-devel] RFC for new features Antony T Curtis
2004-07-08 19:45   ` Jocelyn Mayer
2004-07-08 19:00 ` Karel Gardas
2004-07-08 21:44   ` vaise
2004-07-08 19:30 ` Jean-Michel POURE
2004-07-08 19:48 ` Brad Watson
2004-07-08 21:37 ` Jan Dittmer
2004-07-08 22:24 ` malc
2004-07-08 19:35   ` Jim C. Brown
2004-07-09 20:27 ` [Qemu-devel] " Emmanuel Charpentier
2004-07-09 22:13   ` Antony T Curtis
2004-07-10  0:38     ` Derek Fawcus
2004-07-10  2:44     ` [Qemu-devel] 3Dfx... Just guessing Natalia Portillo
2004-07-10 13:06       ` Fabrice Bellard
2004-07-10 20:41         ` Natalia Portillo
2004-07-11 21:20           ` Ishwar Rattan
2004-07-11 22:42             ` Natalia Portillo
2004-07-11  1:10       ` Jim C. Brown
2004-07-11 11:16         ` Gianni Tedesco
2004-07-11  4:45     ` Re[2]: [Qemu-devel] Re: RFC for new features Igor Shmukler
2004-07-09 21:51 ` [Qemu-devel] (Before) " Hetz Ben Hamo
2004-07-09  9:50   ` Johannes Schindelin
2004-07-10 11:49     ` [Qemu-devel] plugins Hetz Ben Hamo
2004-07-09 13:25       ` Lionel Ulmer
2004-07-10 15:23         ` Hetz Ben Hamo
2004-07-09 13:35       ` Bartosz Fabianowski
2004-07-09 13:48         ` Gianni Tedesco [this message]
2004-07-09 13:39       ` Gianni Tedesco

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=1089380928.3101.21.camel@sherbert \
    --to=gianni@scaramanga.co.uk \
    --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).