Il 30/06/2014 19:31, Will Deacon ha scritto:
> It would let Will keep the simpler code with an array, and autogenerate
> KVM_DEV_TYPE_MAX.
Although this is uapi, so we may need to #define the symbols anyway to avoid
breaking userspace #ifndef tests.
What do you reckon; is this an ABI break?
Y
On Mon, Jun 30, 2014 at 06:22:55PM +0100, Paolo Bonzini wrote:
> Il 30/06/2014 11:21, Cornelia Huck ha scritto:
> > On Thu, 26 Jun 2014 18:30:16 +0100
> > Will Deacon wrote:
> >> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> >> index e11d8f170a62..3b368166286f 100644
> >> ---
On Mon, 30 Jun 2014 19:22:55 +0200
Paolo Bonzini wrote:
> Il 30/06/2014 11:21, Cornelia Huck ha scritto:
> > On Thu, 26 Jun 2014 18:30:16 +0100
> > Will Deacon wrote:
> >
> >> kvm_ioctl_create_device currently has knowledge of all the device types
> >> and their associated ops. This is fairly in
Il 30/06/2014 11:21, Cornelia Huck ha scritto:
On Thu, 26 Jun 2014 18:30:16 +0100
Will Deacon wrote:
kvm_ioctl_create_device currently has knowledge of all the device types
and their associated ops. This is fairly inflexible when adding support
for new in-kernel device emulations, so move what
On Mon, Jun 30, 2014 at 12:14:27PM +0100, Cornelia Huck wrote:
> On Fri, 27 Jun 2014 16:17:57 +0200
> Paolo Bonzini wrote:
>
> > Il 26/06/2014 19:30, Will Deacon ha scritto:
> > > kvm_ioctl_create_device currently has knowledge of all the device types
> > > and their associated ops. This is fairl
On Fri, 27 Jun 2014 16:17:57 +0200
Paolo Bonzini wrote:
> Il 26/06/2014 19:30, Will Deacon ha scritto:
> > kvm_ioctl_create_device currently has knowledge of all the device types
> > and their associated ops. This is fairly inflexible when adding support
> > for new in-kernel device emulations, s
On Fri, Jun 27, 2014 at 03:17:57PM +0100, Paolo Bonzini wrote:
> Il 26/06/2014 19:30, Will Deacon ha scritto:
> > kvm_ioctl_create_device currently has knowledge of all the device types
> > and their associated ops. This is fairly inflexible when adding support
> > for new in-kernel device emulatio
On Mon, Jun 30, 2014 at 11:25:01AM +0100, Cornelia Huck wrote:
> On Mon, 30 Jun 2014 10:36:19 +0100
> Will Deacon wrote:
> > On Mon, Jun 30, 2014 at 10:21:14AM +0100, Cornelia Huck wrote:
> > > On Thu, 26 Jun 2014 18:30:16 +0100
> > > Will Deacon wrote:
> > > > diff --git a/include/uapi/linux/kvm
On Mon, 30 Jun 2014 10:36:19 +0100
Will Deacon wrote:
> Hello,
>
> On Mon, Jun 30, 2014 at 10:21:14AM +0100, Cornelia Huck wrote:
> > On Thu, 26 Jun 2014 18:30:16 +0100
> > Will Deacon wrote:
> > > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> > > index e11d8f170a62..3b368
Hello,
On Mon, Jun 30, 2014 at 10:21:14AM +0100, Cornelia Huck wrote:
> On Thu, 26 Jun 2014 18:30:16 +0100
> Will Deacon wrote:
>
> > kvm_ioctl_create_device currently has knowledge of all the device types
> > and their associated ops. This is fairly inflexible when adding support
> > for new in
On Thu, 26 Jun 2014 18:30:16 +0100
Will Deacon wrote:
> kvm_ioctl_create_device currently has knowledge of all the device types
> and their associated ops. This is fairly inflexible when adding support
> for new in-kernel device emulations, so move what we currently have out
> into a table, which
Il 26/06/2014 19:30, Will Deacon ha scritto:
kvm_ioctl_create_device currently has knowledge of all the device types
and their associated ops. This is fairly inflexible when adding support
for new in-kernel device emulations, so move what we currently have out
into a table, which can support dyna
kvm_ioctl_create_device currently has knowledge of all the device types
and their associated ops. This is fairly inflexible when adding support
for new in-kernel device emulations, so move what we currently have out
into a table, which can support dynamic registration of ops by new
drivers for virt
13 matches
Mail list logo
