All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Avi Kivity <avi@qumranet.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/13] KVM: virtualization infrastructure
Date: Mon, 23 Oct 2006 22:35:29 +0200	[thread overview]
Message-ID: <200610232235.29287.arnd@arndb.de> (raw)
In-Reply-To: <453D2604.5010208@qumranet.com>

On Monday 23 October 2006 22:28, Avi Kivity wrote:

> >> +struct segment_descriptor {
> >> +    u16 limit_low;
> >> +    u16 base_low;
> >> +    u8  base_mid;
> >> +    u8  type : 4;
> >> +    u8  system : 1;
> >> +    u8  dpl : 2;
> >> +    u8  present : 1;
> >> +    u8  limit_high : 4;
> >> +    u8  avl : 1;
> >> +    u8  long_mode : 1;
> >> +    u8  default_op : 1;
> >> +    u8  granularity : 1;
> >> +    u8  base_high;
> >> +} __attribute__((packed));
> >>    
> >
> > Bitfields are generally frowned upon. It's better to define
> > constants for each of these and use a u64.
>
> Any specific reasons?  I find the code much more readable (and
> lowercase) with bitfields.

The strongest reason against bitfields is that they are not
endian-clean. This doesn't apply on a architecture-specific
patch such as KVM, but it just feels wrong to read code
with bit fields in the kernel.

> The structure's size is defined by the hardware (struvt vmcs is just a
> header).  In addition, current_vmcs changes when another guest is
> switched in (it is somewhat like the scheduler's current for the VT
> hardware).

Ok, I see.

> >> +static long kvm_dev_ioctl(struct file *filp,
> >> +                      unsigned int ioctl, unsigned long arg)
> >> +{
> >> +    struct kvm *kvm = filp->private_data;
> >> +    int r = -EINVAL;
> >> +
> >> +    switch (ioctl) {
> >> +    default:
> >> +            ;
> >> +    }
> >> +out:
> >> +    return r;
> >> +}
> >>    
> >
> > Huh? Just leave out stuff like this. If the ioctl function is introduced
> > in a later patch, you can still add the whole function there. 
>
> Several different patches add content here, so I thought I wouldn't play
> favorite.
>
> It also makes reordering the patches a little less painful.  Any tips on
> that or is that a normal ramp up?  I'm using quilt for now and syncing
> to a conventional source control repository.

I saw later how you add specific calls to this function. I guess it's
already as good as it gets, so just leave it this way.

	Arnd <><

  reply	other threads:[~2006-10-23 20:35 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-23 13:28 [PATCH 0/7] KVM: Kernel-based Virtual Machine (v2) Avi Kivity
2006-10-23 13:29 ` [PATCH 1/13] KVM: userspace interface Avi Kivity
2006-10-24 12:51   ` Muli Ben-Yehuda
2006-10-24 12:56     ` Avi Kivity
2006-10-24 12:59       ` Muli Ben-Yehuda
2006-10-23 13:29 ` [PATCH 2/13] KVM: Intel virtual mode extensions definitions Avi Kivity
2006-10-23 13:30 ` [PATCH 3/13] KVM: kvm data structures Avi Kivity
2006-10-23 13:30 ` [PATCH 4/13] KVM: random accessors and constants Avi Kivity
2006-10-23 13:30 ` [PATCH 5/13] KVM: virtualization infrastructure Avi Kivity
2006-10-23 19:35   ` Arnd Bergmann
2006-10-23 20:28     ` Avi Kivity
2006-10-23 20:35       ` Arnd Bergmann [this message]
2006-10-23 20:39         ` Avi Kivity
2006-10-24 12:03         ` Avi Kivity
2006-10-24  5:19           ` Andi Kleen
2006-10-24 13:43             ` [PATCH] x86: Extract segment descriptor definitions for use outside of x86_64 Avi Kivity
2006-10-24 14:10               ` Andi Kleen
2006-10-23 13:30 ` [PATCH 6/13] KVM: memory slot management Avi Kivity
2006-10-23 13:30 ` [PATCH 7/13] KVM: vcpu creation and maintenance Avi Kivity
2006-10-23 13:30 ` [PATCH 8/13] KVM: vcpu execution loop Avi Kivity
     [not found]   ` <200610232141.45802.arnd@arndb.de>
2006-10-23 20:16     ` Avi Kivity
2006-10-23 20:29       ` Arnd Bergmann
2006-10-23 20:37         ` Avi Kivity
2006-10-23 21:02           ` Antonio Vargas
2006-10-23 21:11             ` Avi Kivity
2006-10-23 22:08               ` Antonio Vargas
2006-10-23 22:18           ` Arnd Bergmann
2006-10-23 13:31 ` [PATCH 9/13] KVM: define exit handlers Avi Kivity
2006-10-24  1:05   ` Anthony Liguori
2006-10-24  7:23     ` Avi Kivity
2006-10-23 13:31 ` [PATCH 10/13] KVM: less common " Avi Kivity
2006-10-23 13:31 ` [PATCH 11/13] KVM: mmu Avi Kivity
2006-10-23 13:31 ` [PATCH 12/13] KVM: x86 emulator Avi Kivity
2006-10-23 13:31 ` [PATCH 13/13] KVM: plumbing Avi Kivity
2006-10-23 13:44 ` [PATCH 0/7] KVM: Kernel-based Virtual Machine (v2) Avi Kivity
2006-10-23 15:38 ` [PATCH 0/13] KVM: qemu patch Avi Kivity
  -- strict thread matches above, loose matches on Subject: below --
2006-10-26 17:19 [PATCH 0/13] KVM: Kernel-based Virtual Machine (v3) Avi Kivity
2006-10-26 17:26 ` [PATCH 5/13] KVM: virtualization infrastructure Avi Kivity

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=200610232235.29287.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=avi@qumranet.com \
    --cc=linux-kernel@vger.kernel.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.