qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Michael Tokarev <mjt@tls.msk.ru>, qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] RFC: DSO (dynamic shared objects) support
Date: Tue, 18 Jun 2013 15:13:54 +0200	[thread overview]
Message-ID: <51C05D12.1050104@redhat.com> (raw)
In-Reply-To: <CA+aC4kt0w_zzHNgoTvHozf80NPkX9qPzdf4-RkVWVYfVhuTWSw@mail.gmail.com>

Il 18/06/2013 14:42, Anthony Liguori ha scritto:
>> > Next, and this is the most complex part.  The build system for
>> > modules, and configuring it.   I heard there were plans to use
>> > something like kbuild system for that, has anything been done
>> > in this context?
> GSoC just kicked off yesterday.  Paolo can perhaps shed some light on
> what the plans are.

The plans is just to add kconfig, not kbuild, similar to
seabios/busybox/etc.

It would provide configurability by target and board, and in addition
make it obvious which bits of default-configs/ (such as PCI, USB, HPET,
etc.) are actually configurable.

I outlined a possible implementation at the end of
http://wiki.qemu.org/Features/Modules, though something nicer may be
possible (possibly taking inspiration from Kconfig).

>> > With current config/build system, the following changes are
>> > needed:
>> >
>> >  o split individual libs from libs_softmmu into their own
>> >    variables.

Ack.  This could be doable already and independent from everything else.

>> >  o allow obj-m (and similar) in addition to obj-y, with build
>> >    flags and rules to produce an .so.
> We also need a way to define the module targets.  My Makefile-fu is
> not all that great but I suspect we can do something like:
> 
> libqemu-%.ko: $(eval $(obj-%-m))
> 
> I don't think that works but that's the rough idea.  We would then
> need to define each module target by hand but that's probably
> reasonable in the short term until we have kconfig.

You can limit that to multiple-source modules, which is the common case.
 Single-source modules are easily handled.

Paolo

  parent reply	other threads:[~2013-06-18 13:14 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-18 11:37 [Qemu-devel] RFC: DSO (dynamic shared objects) support Michael Tokarev
2013-06-18 12:05 ` Laszlo Ersek
2013-06-18 13:06   ` Paolo Bonzini
2013-06-18 12:17 ` Laszlo Ersek
2013-06-18 12:19   ` Michael Tokarev
2013-06-18 12:28     ` Michael Tokarev
2013-06-18 20:15   ` Daniel P. Berrange
2013-06-18 21:40     ` Richard Henderson
2013-06-18 12:42 ` Anthony Liguori
2013-06-18 13:12   ` Peter Maydell
2013-06-18 13:32     ` Paolo Bonzini
2013-06-18 13:13   ` Paolo Bonzini [this message]
2013-06-18 20:19   ` Daniel P. Berrange
2013-06-18 21:34     ` Peter Maydell
2013-06-18 19:35 ` Richard Henderson

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=51C05D12.1050104@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=mjt@tls.msk.ru \
    --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).