From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5b89650d4d64f43d10f377335596f718@terzarima.net> To: 9fans@cse.psu.edu Subject: Re: [9fans] 8c question From: Charles Forsyth Date: Fri, 8 Jul 2005 12:14:45 +0100 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-gqoiyztpyvshxunfekhxalywss" Topicbox-Message-UUID: 632f9022-ead0-11e9-9d60-3106f5b1d025 This is a multi-part message in MIME format. --upas-gqoiyztpyvshxunfekhxalywss Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit sorry, i hadn't properly understood the context in which those declarations were used. i'll look at them again with that in mind. --upas-gqoiyztpyvshxunfekhxalywss Content-Type: message/rfc822 Content-Disposition: inline Received: from mail.cse.psu.edu ([130.203.4.6]) by lavoro; Fri Jul 8 04:31:48 BST 2005 Received: from psuvax1.cse.psu.edu (localhost [127.0.0.1]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id F285118F76 for ; Thu, 7 Jul 2005 23:31:35 -0400 (EDT) X-Original-To: 9fans@cse.psu.edu Delivered-To: 9fans@cse.psu.edu Received: from localhost (localhost [127.0.0.1]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 9AA9717CFE for <9fans@cse.psu.edu>; Thu, 7 Jul 2005 23:31:04 -0400 (EDT) Received: from mail.cse.psu.edu ([127.0.0.1]) by localhost (psuvax1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 20191-01-40 for <9fans@cse.psu.edu>; Thu, 7 Jul 2005 23:31:02 -0400 (EDT) Received: from ensemada.lava.net (ensemada.lava.net [64.65.64.27]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 142EC17CE8 for <9fans@cse.psu.edu>; Thu, 7 Jul 2005 23:31:02 -0400 (EDT) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by ensemada.lava.net (Postfix) with ESMTP id EC0A03010A for <9fans@cse.psu.edu>; Thu, 7 Jul 2005 17:31:00 -1000 (HST) Date: Thu, 7 Jul 2005 17:31:00 -1000 (HST) From: Tim Newsham To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] 8c question In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 9fans-bounces+forsyth=terzarima.net@cse.psu.edu Errors-To: 9fans-bounces+forsyth=terzarima.net@cse.psu.edu > i don't understand. if it's in the portability interface, > you say what arch_vcpu_info_t is, so why not > typedef int arch_vcpu_info_t; > and be done with it. i don't see why it must be a struct > in that context. Typedefing it to an int would be fine, except then it will be four bytes larger in Plan9 than it is in the Xen host. Since this is a shared data structure, bad things will happen. I think I might be able to get them to set it to some fixed length size and just waste some space. Its just a matter of me getting time to create a patch and test it and submit it. Tim Newsham http://www.lava.net/~newsham/ --upas-gqoiyztpyvshxunfekhxalywss--