All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grzegorz Milos <gm281@cam.ac.uk>
To: Keir Fraser <keir@xensource.com>
Cc: Dietmar Hahn <dietmar.hahn@fujitsu-siemens.com>,
	xen-devel@lists.xensource.com,
	Xen-ia64-devel <xen-ia64-devel@lists.xensource.com>
Subject: Re: [RFC][PATCH]mini-os: big-endian mini-os on ia64
Date: Thu, 01 Mar 2007 22:08:05 +0000	[thread overview]
Message-ID: <45E74EC5.6070300@cam.ac.uk> (raw)
In-Reply-To: <C209BDCA.A355%keir@xensource.com>

>> 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.

Cheers
Gregor

  parent reply	other threads:[~2007-03-01 22:08 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-20 14:00 [RFC][PATCH]mini-os: big-endian mini-os on ia64 Dietmar Hahn
2007-02-20 14:36 ` Keir Fraser
2007-02-20 14:51   ` [Xen-devel] " Dietmar Hahn
2007-02-20 19:03     ` Grzegorz Milos
2007-02-21 13:04       ` [Xen-devel] " Dietmar Hahn
2007-02-21 13:51         ` Keir Fraser
2007-02-27  9:55           ` [Xen-devel] " Dietmar Hahn
2007-02-27 10:51             ` Keir Fraser
2007-02-27 12:07               ` Mark Williamson
2007-02-28  8:21                 ` [Xen-devel] " Dietmar Hahn
2007-02-28  8:42                   ` Keir Fraser
2007-02-28 10:14                     ` [Xen-devel] " Dietmar Hahn
2007-02-28  8:25               ` Dietmar Hahn
2007-02-28  8:37                 ` Keir Fraser
2007-02-28  9:05                   ` Dietmar Hahn
2007-03-01 22:08               ` Grzegorz Milos [this message]
2007-03-15 10:55                 ` Dietmar Hahn
2007-03-15 11:01                   ` Dietmar Hahn

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=45E74EC5.6070300@cam.ac.uk \
    --to=gm281@cam.ac.uk \
    --cc=dietmar.hahn@fujitsu-siemens.com \
    --cc=keir@xensource.com \
    --cc=xen-devel@lists.xensource.com \
    --cc=xen-ia64-devel@lists.xensource.com \
    /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.