WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

Re: [Xen-ia64-devel] [xen-ia64][PATCH]New set OS type method

To: "Zhang, Xing Z" <xing.z.zhang@xxxxxxxxx>
Subject: Re: [Xen-ia64-devel] [xen-ia64][PATCH]New set OS type method
From: Alex Williamson <alex.williamson@xxxxxx>
Date: Wed, 21 Nov 2007 07:00:31 -0700
Cc: xen-ia64-devel <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 21 Nov 2007 06:01:25 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <823A93EED437D048963A3697DB0E35DEE7023F@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: HP OSLO R&D
References: <823A93EED437D048963A3697DB0E35DEE7023F@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Wed, 2007-11-21 at 18:35 +0800, Zhang, Xing Z wrote:
> Hi Alex:
>       This patch add an OS type configure entry in script. It can replace 
> _OSI interface. 
>       User may use below format to set OS type:
> 
> In a xmexample.vti:
> # 0xB0:unknown
> # 0xB1:windows
> # 0xB2:linux
> #default is unknown
> Guest_os_type=0xB1
> 
> Comments are welcome.

Hi Wing,

   Thanks for looking into this.  Your implementation is kind of along
the lines I was thinking.  Would it make more sense to represent
Guest_os_type as a fixed length string?  There's no reason to stay with
the 0xBx specification if we're doing this through the config file (and
as a user, its unnecessarily complicated).  The down side is that it
gives the user more opportunity to make a mistake, but I think if we
give the known useful values in the example file it should be ok.  We'll
have to work with upstream on a config variable that might be
generically useful to others.

   The other question is whether we parse the string in Xen or in the
domain builder tools.  For instance, the tools might parse "Windows" and
set flags that regions 4 & 5 are identity mapped instead of just passing
that "Windows" string into Xen.  I don't know if this really adds
anything or just keeps string parsing out of Xen.

   BTW, I see your e100 driver is now in upstream.  Good work!  I'll
merge that in and try it.  Thanks again for looking at this.

        Alex

-- 
Alex Williamson                             HP Open Source & Linux Org.


_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel