This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [RFC][PATCH]mini-os: big-endian mini-os on ia64

To: Keir Fraser <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [RFC][PATCH]mini-os: big-endian mini-os on ia64
From: Grzegorz Milos <gm281@xxxxxxxxx>
Date: Thu, 01 Mar 2007 22:08:05 +0000
Cc: Dietmar Hahn <dietmar.hahn@xxxxxxxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Xen-ia64-devel <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 01 Mar 2007 14:07:32 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C209BDCA.A355%keir@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C209BDCA.A355%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5 (X11/20051025)
What I want to have is a mini-os, where everybody whith ia64 hardware can
build and run a BE mini-os beside LE mini-os (or other domU's) on xen-ia64
hypervisor. If you say at this point: no interrest for such a thing, than we
can stop this discussion here.

I don;t think we'd have a problem with incorportaing support for ia64-be if
there's a good reason for it (a better reason than "because it's possible").

The other way would be building wrappers around all the accesses to
domU/hypervisor interfaces and hide the SWAPs there. But this seems a little
bit overkill at this stage.

It would be less ugly and I think less prone to missing some open-coded
accesses. Open-coding the SWAP()s is pretty grim.

One solution to the rotting problem would be write regression tests. High level tests (like for example netfront test) would be quite good at picking missing SWAPs, since they exercise a fair amount of Xen/Dom0 interfaces. Still it's quite hard to check the coverage (anybody happens to be an expert on coverage testing?).

I too dislike scattering SWAPs all over the code, but I guess having a nice set of wrappers would at least confine the problem. Still ... not that fond of it.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>