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

Re: [Xen-devel] RFC: 32 bits as smallest atomic size.

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] RFC: 32 bits as smallest atomic size.
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Sun, 27 Mar 2005 12:19:14 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx, "Ronald G. Minnich" <rminnich@xxxxxxxx>, Jimi Xenidis <jimix@xxxxxxxxxxxxxx>
Delivery-date: Sun, 27 Mar 2005 11:21:31 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <b44b561aa3958105c8613c6364b6a6da@xxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
References: <16964.33214.921809.324278@xxxxxxxxxxxxxxxxxxxxx> <74f362598b4e1a0d46aacb1a514706ac@xxxxxxxxxxxx> <16964.41853.43756.836319@xxxxxxxxxxxxxxxxxxxxx> <Pine.LNX.4.58.0503261029270.23670@xxxxxxxxxxxxxxx> <16965.40068.388024.929154@xxxxxxxxxxxxxxxxxxxxx> <21eeeb49a66395420f0c47c7d5327630@xxxxxxxxxxxx> <2330d67d198017769ff97ec4a548dcf2@xxxxxxxxxxxx> <Pine.LNX.4.58.0503262030500.24687@xxxxxxxxxxxxxxx> <b44b561aa3958105c8613c6364b6a6da@xxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx

On 27 Mar 2005, at 11:56, Keir Fraser wrote:

I don't think there are that many gcc-isms, apart from use of PACKED (please correct me if I'm wrong). You can always define that to nothing if you need to - I'd hope that no compiler adds padding since all fields should be naturally aligned. I don't see us moving to a model where we define macros on char arrays anytime soon. :-) But perhaps we could include a script to generate such macros from our structure definitions....

Actually this would get round the need to manually determine field offsets -- we could get rid of PACKED, let fields fall as they may, and then run the headers through gcc to get field offsets for those who need them. There are a very few cases where we actually really care about two fields being directly adjacent, but I could add annotations in the header files and run a script to check that the placement constraints are satisfied.

Already the field offset comments are broken in a few places in unstable, so perhaps this is a better way to go.

 -- Keir



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel

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