[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Unified device model

From: Paul Brook
Subject: Re: [Qemu-devel] Unified device model
Date: Sun, 9 Apr 2006 16:21:42 +0100
User-agent: KMail/1.9.1

> > 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]