All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Glauber Costa <glommer@redhat.com>
Cc: aliguori@us.ibm.com, Avi Kivity <avi@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: [PATCH] create kvm-shared-all.c and	kvm-shared.h
Date: Tue, 09 Jun 2009 18:51:24 +0200	[thread overview]
Message-ID: <4A2E930C.8090708@siemens.com> (raw)
In-Reply-To: <20090609165123.GQ11966@poweredge.glommer>

Glauber Costa wrote:
> On Tue, Jun 09, 2009 at 06:42:44PM +0200, Jan Kiszka wrote:
>> Glauber Costa wrote:
>>> On Tue, Jun 09, 2009 at 07:26:58PM +0300, Avi Kivity wrote:
>>>> Jan Kiszka wrote:
>>>>> Glauber Costa wrote:
>>>>>   
>>>>>> Following a suggestion given by Jan, the idea here is to
>>>>>> move shared pieces between qemu and qemu-kvm.git into a common
>>>>>> file, so we can do sharing while avoid clashes.
>>>>>>
>>>>>> In the future, this files should disappear.
>>>>>>
>>>>>>     
>>>>> OK for the header - but why do we have to push the ioctl services into a
>>>>> separate module? Will all functions qemu-kvm start to use from upstream
>>>>> have to be pushed around? Or what is special about the ioctls?
>>>>>
>>>>> I rather think qemu-kvm should build kvm-all.c and #ifdef out those
>>>>> parts which collide with its own implementation. Moreover, when we morph
>>>>> qemu-kvm services for upstream, this could already happen where they
>>>>> shall once be located: in kvm-all.c or target-*/kvm.c.
>>>>>   
>>>> Yes, we could simply append libkvm-all.c and qemu-kvm.c to kvm-all.c,  
>>>> and gradually include more of kvm-all.c as we delete parts of libkvm.c  
>>>> and qemu-kvm.c.
>>> I tried it myself, and it generates tons of conflicts. So scary.
>>> I'd prefer to do it in the way I propose, until there is nothing left on kvm-all.c
>>>
>> kvm-all.c:
>>
>> #ifdef DONT_USE_UPSTREAM_YET
>> <upstream code>
>> #endif
>>
>> int kvm_ioctl(KVMState *s, int type, ...)
>> ...
>>
>> #ifdef DONT_USE_UPSTREAM_YET
>> <some more upstream code>
>> #endif
>>
>> <libkvm code>
>>
>>
>> Can't imagine that this is infeasible. And it would all happily live in
>> qemu-kvm, so upstream would never see these hacks.
> yeah, if it is in fact ifdef'd this way, it of course works.
> 
> I can do that, definitely.
> But by doing that, we probably does not even need the header part here too.
> 

I think we need it as long as qemu-kvm-<arch> fiddles with state fields
directly. If that is easily resolvable, I'm all for doing that first and
skipping the kvm-shared.h part in upstream!

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

  reply	other threads:[~2009-06-09 16:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-09 16:04 [Qemu-devel] [PATCH] create kvm-shared-all.c and kvm-shared.h Glauber Costa
2009-06-09 16:17 ` [Qemu-devel] " Jan Kiszka
2009-06-09 16:26   ` Avi Kivity
2009-06-09 16:39     ` Glauber Costa
2009-06-09 16:42       ` Avi Kivity
2009-06-09 16:42       ` Jan Kiszka
2009-06-09 16:51         ` Glauber Costa
2009-06-09 16:51           ` Jan Kiszka [this message]
2009-06-09 16:37   ` Glauber Costa

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=4A2E930C.8090708@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=aliguori@us.ibm.com \
    --cc=avi@redhat.com \
    --cc=glommer@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.