[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1162809128.3160.201.camel@laptopd505.fenrus.org>
Date: Mon, 06 Nov 2006 11:32:08 +0100
From: Arjan van de Ven <arjan@...radead.org>
To: Avi Kivity <avi@...ranet.com>
Cc: kvm-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org,
akpm@...l.org
Subject: Re: [PATCH 1/14] KVM: userspace interface
> \> as a general rule, it's a lot better to sort structures big-to-small, to
> > make sure alignments inside the struct are minimized and don't suck too
> > much. This is especially important to get right for 32/64 bit
> > compatibility. This comment is true for most structures in this header
> > file; please consider this at least
> >
>
> Doesn't that cause an unnatural field order?
Does it matter?
> for example, in some
> structures I separated in and out variables. Sorting by size is a bit
> like sorting alphabetically.
>
> Anyway I observed 32/64 bit compatibility religiously.
but you did take the alignment rules of 64 bit variables into account,
eg 32 bit has it 4 byte aligned, while 64 bit has it 8 byte aligned..
you are 100% sure even your 32 bit structures have all 64 bit values 8
byte aligned?
(you get this automatic if you sort by size)
Also you made sure that if you have such implicit padding that you zero
out the memory between the fields to avoid information leaks?
Sorting by size at least makes this all go away.....
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists