All of lore.kernel.org
 help / color / mirror / Atom feed
* KVM call agenda for Tuesday, July 3rd
@ 2012-07-02 10:16 ` Juan Quintela
  0 siblings, 0 replies; 10+ messages in thread
From: Juan Quintela @ 2012-07-02 10:16 UTC (permalink / raw)
  To: KVM devel mailing list, qemu-devel


Hi

Please send in any agenda items you are interested in covering.

Later, Juan.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Qemu-devel] KVM call agenda for Tuesday, July 3rd
@ 2012-07-02 10:16 ` Juan Quintela
  0 siblings, 0 replies; 10+ messages in thread
From: Juan Quintela @ 2012-07-02 10:16 UTC (permalink / raw)
  To: KVM devel mailing list, qemu-devel


Hi

Please send in any agenda items you are interested in covering.

Later, Juan.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Qemu-devel] KVM call agenda for Tuesday, July 3rd
  2012-07-02 10:16 ` [Qemu-devel] " Juan Quintela
@ 2012-07-02 17:33   ` Eric Blake
  -1 siblings, 0 replies; 10+ messages in thread
From: Eric Blake @ 2012-07-02 17:33 UTC (permalink / raw)
  To: quintela; +Cc: KVM devel mailing list, qemu-devel

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

On 07/02/2012 04:16 AM, Juan Quintela wrote:
> 
> Hi
> 
> Please send in any agenda items you are interested in covering.

Can we discuss the future of 'getfd', the possibility of 'pass-fd', or
even the enhancement of all existing monitor commands to take an
optional 'nfds' JSON argument for atomic management of fd passing?
Which commands need to reopen a file with different access, and do we
bite the bullet to special case all of those commands to allow fd
passing or can we make qemu_open() coupled with high-level fd passing
generic enough to satisfy all of our reopen needs?

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Qemu-devel] KVM call agenda for Tuesday, July 3rd
@ 2012-07-02 17:33   ` Eric Blake
  0 siblings, 0 replies; 10+ messages in thread
From: Eric Blake @ 2012-07-02 17:33 UTC (permalink / raw)
  To: quintela; +Cc: qemu-devel, KVM devel mailing list

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

On 07/02/2012 04:16 AM, Juan Quintela wrote:
> 
> Hi
> 
> Please send in any agenda items you are interested in covering.

Can we discuss the future of 'getfd', the possibility of 'pass-fd', or
even the enhancement of all existing monitor commands to take an
optional 'nfds' JSON argument for atomic management of fd passing?
Which commands need to reopen a file with different access, and do we
bite the bullet to special case all of those commands to allow fd
passing or can we make qemu_open() coupled with high-level fd passing
generic enough to satisfy all of our reopen needs?

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: KVM call agenda for Tuesday, July 3rd
  2012-07-02 10:16 ` [Qemu-devel] " Juan Quintela
@ 2012-07-03  3:59   ` 王永博
  -1 siblings, 0 replies; 10+ messages in thread
From: 王永博 @ 2012-07-03  3:59 UTC (permalink / raw)
  To: quintela; +Cc: KVM devel mailing list, qemu-devel

does KVM  have the function like vmsafe to develop security software
for Virtualization 。

2012/7/2 Juan Quintela <quintela@redhat.com>:
>
> Hi
>
> Please send in any agenda items you are interested in covering.
>
> Later, Juan.
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Qemu-devel] KVM call agenda for Tuesday, July 3rd
@ 2012-07-03  3:59   ` 王永博
  0 siblings, 0 replies; 10+ messages in thread
From: 王永博 @ 2012-07-03  3:59 UTC (permalink / raw)
  To: quintela; +Cc: qemu-devel, KVM devel mailing list

does KVM  have the function like vmsafe to develop security software
for Virtualization 。

2012/7/2 Juan Quintela <quintela@redhat.com>:
>
> Hi
>
> Please send in any agenda items you are interested in covering.
>
> Later, Juan.
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Qemu-devel] KVM call agenda for Tuesday, July 3rd
  2012-07-02 17:33   ` Eric Blake
@ 2012-07-03 12:33     ` Kevin Wolf
  -1 siblings, 0 replies; 10+ messages in thread
From: Kevin Wolf @ 2012-07-03 12:33 UTC (permalink / raw)
  To: Eric Blake; +Cc: quintela, qemu-devel, KVM devel mailing list, Corey Bryant

Am 02.07.2012 19:33, schrieb Eric Blake:
> On 07/02/2012 04:16 AM, Juan Quintela wrote:
>>
>> Hi
>>
>> Please send in any agenda items you are interested in covering.
> 
> Can we discuss the future of 'getfd', the possibility of 'pass-fd', or
> even the enhancement of all existing monitor commands to take an
> optional 'nfds' JSON argument for atomic management of fd passing?
> Which commands need to reopen a file with different access, and do we
> bite the bullet to special case all of those commands to allow fd
> passing or can we make qemu_open() coupled with high-level fd passing
> generic enough to satisfy all of our reopen needs?

Sure we can, at least if Corey will attend the call. Otherwise I guess
it's better to keep the discussion on the mailing list.

Kevin

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Qemu-devel] KVM call agenda for Tuesday, July 3rd
@ 2012-07-03 12:33     ` Kevin Wolf
  0 siblings, 0 replies; 10+ messages in thread
From: Kevin Wolf @ 2012-07-03 12:33 UTC (permalink / raw)
  To: Eric Blake; +Cc: Corey Bryant, qemu-devel, KVM devel mailing list, quintela

Am 02.07.2012 19:33, schrieb Eric Blake:
> On 07/02/2012 04:16 AM, Juan Quintela wrote:
>>
>> Hi
>>
>> Please send in any agenda items you are interested in covering.
> 
> Can we discuss the future of 'getfd', the possibility of 'pass-fd', or
> even the enhancement of all existing monitor commands to take an
> optional 'nfds' JSON argument for atomic management of fd passing?
> Which commands need to reopen a file with different access, and do we
> bite the bullet to special case all of those commands to allow fd
> passing or can we make qemu_open() coupled with high-level fd passing
> generic enough to satisfy all of our reopen needs?

Sure we can, at least if Corey will attend the call. Otherwise I guess
it's better to keep the discussion on the mailing list.

Kevin

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: KVM call agenda for Tuesday, July 3rd
  2012-07-03 12:33     ` Kevin Wolf
@ 2012-07-03 13:14       ` Corey Bryant
  -1 siblings, 0 replies; 10+ messages in thread
From: Corey Bryant @ 2012-07-03 13:14 UTC (permalink / raw)
  To: Kevin Wolf; +Cc: Eric Blake, qemu-devel, KVM devel mailing list, quintela



On 07/03/2012 08:33 AM, Kevin Wolf wrote:
> Am 02.07.2012 19:33, schrieb Eric Blake:
>> On 07/02/2012 04:16 AM, Juan Quintela wrote:
>>>
>>> Hi
>>>
>>> Please send in any agenda items you are interested in covering.
>>
>> Can we discuss the future of 'getfd', the possibility of 'pass-fd', or
>> even the enhancement of all existing monitor commands to take an
>> optional 'nfds' JSON argument for atomic management of fd passing?
>> Which commands need to reopen a file with different access, and do we
>> bite the bullet to special case all of those commands to allow fd
>> passing or can we make qemu_open() coupled with high-level fd passing
>> generic enough to satisfy all of our reopen needs?
>
> Sure we can, at least if Corey will attend the call. Otherwise I guess
> it's better to keep the discussion on the mailing list.
>
> Kevin
>

I'll be on the call.  Thanks for getting this on the agenda.

-- 
Regards,
Corey

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Qemu-devel] KVM call agenda for Tuesday, July 3rd
@ 2012-07-03 13:14       ` Corey Bryant
  0 siblings, 0 replies; 10+ messages in thread
From: Corey Bryant @ 2012-07-03 13:14 UTC (permalink / raw)
  To: Kevin Wolf; +Cc: Eric Blake, qemu-devel, KVM devel mailing list, quintela



On 07/03/2012 08:33 AM, Kevin Wolf wrote:
> Am 02.07.2012 19:33, schrieb Eric Blake:
>> On 07/02/2012 04:16 AM, Juan Quintela wrote:
>>>
>>> Hi
>>>
>>> Please send in any agenda items you are interested in covering.
>>
>> Can we discuss the future of 'getfd', the possibility of 'pass-fd', or
>> even the enhancement of all existing monitor commands to take an
>> optional 'nfds' JSON argument for atomic management of fd passing?
>> Which commands need to reopen a file with different access, and do we
>> bite the bullet to special case all of those commands to allow fd
>> passing or can we make qemu_open() coupled with high-level fd passing
>> generic enough to satisfy all of our reopen needs?
>
> Sure we can, at least if Corey will attend the call. Otherwise I guess
> it's better to keep the discussion on the mailing list.
>
> Kevin
>

I'll be on the call.  Thanks for getting this on the agenda.

-- 
Regards,
Corey

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2012-07-03 13:15 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-07-02 10:16 KVM call agenda for Tuesday, July 3rd Juan Quintela
2012-07-02 10:16 ` [Qemu-devel] " Juan Quintela
2012-07-02 17:33 ` Eric Blake
2012-07-02 17:33   ` Eric Blake
2012-07-03 12:33   ` Kevin Wolf
2012-07-03 12:33     ` Kevin Wolf
2012-07-03 13:14     ` Corey Bryant
2012-07-03 13:14       ` [Qemu-devel] " Corey Bryant
2012-07-03  3:59 ` 王永博
2012-07-03  3:59   ` [Qemu-devel] " 王永博

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.