Re: [Xen-devel] Guidelines for new PV protocol submission

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Jan Beulich writes ("Re: [Xen-devel] Guidelines for new PV protocol 
submission"):
> On 20.01.15 at 14:39, <andrew.cooper3@xxxxxxxxxx> wrote:
> > It is far nicer to work from a document than to worry how another
> > compiler might change the structure.
> 
> Compilers have (almost, i.e. leaving aside bitfields) no freedom in laying
> out structures - any platform's ABI defines how this needs to be done.
> Or else code compiled with different compilers wouldn't inter-operate.

This is true within an ABI on a particular operating system, but there
is nothing stopping an operating system from supporting multiple ABIs.
There is nothing stopping an operating system from using an ABI whose
struct layout rules are different to those specified in the processor
manufacturer's reference manuals.  (Perhaps even only such an ABI.
Embedded OS developers often decide ABI details for themselves.)

Also, a processor manufacturer who invents a new sub-architecture (eg,
a 64-bit version of an existing 32-bit architecture) may decide to
apply new structure layout rules.  So trying to define things in terms
of C structs can lead to data layouts which are different on different
sub-architectures all of which can run on the same CPUs, which is
highly undesirable.  Using uintNN_t types helps with this but is not
sufficient.

Looking at things more formally: if we intend to publish a binary
protocol specification, doing so as a C struct means that we are
implicitly including not just the C specification but also the C
standard and all the processor manufacturers' struct layout rules into
our specification.  The result is a specification where definitively
determining the meaning is an awful lot of work.

And because we are making assumptions about struct layout rules beyond
what is specified in the C standard itself, we may encounter (ie, want
to port Xen to) an architecture where the same struct results in a
different layout - so the specification as a C struct is (in
principle, and sometimes in practice too) not stable across
architectures.

I am 100% in agreement with Roger's proposal.  I think we should
extend this principle to as much of the guest ABI as possible, not
just PV protocols - it would be good to do it for guest-visible
hypervisor and tools ABIs too.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel