From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH/RFC 2/2] s390 virtualization interface. Date: Tue, 1 May 2007 23:12:11 +0200 Message-ID: <200705012312.11692.arnd@arndb.de> References: <1177681235.5770.22.camel@cotte.boeblingen.de.ibm.com> <200704271853.41523.arnd@arndb.de> <20070429080039.GA8332@osiris.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, cborntra-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org, schwidefsky-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org To: Heiko Carstens Return-path: In-Reply-To: <20070429080039.GA8332-5VkHqLvV2o3MbYB6QlFGEg@public.gmane.org> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org On Sunday 29 April 2007, Heiko Carstens wrote: > > Is this data structure extensible? If it is, you probably need > > some sort of versioning information to make sure that user space > > doesn't rely on fields that the kernel doesn't know about. > = > I don't think we can put in some versioning information here. If > the kernel decides to increase the version then old userspace > code would break? > We rather need some mechanism so userpace can ask the kernel > "do you support feature x?" and dependent on the answer some > fields are used or unused. You could do it the way that ext2 handles compatible and incompatible features in the on-disk layout: Assign a number of bits in the read-only part of the mapping to flags that the user application can test. A bit in the compatible range mean that a feature is available to the user application if it wants to use it. A bit in the incompatible range means that the user space needs to understand how to use a feature in order to run correctly. > > > +struct sca_entry { > > > +=A0=A0=A0atomic_t scn; > > > +=A0=A0=A0__u64=A0=A0=A0reserved; > > > +=A0=A0=A0__u64=A0=A0=A0sda; > > > +=A0=A0=A0__u64=A0=A0=A0reserved2[2]; > > > +}__attribute__((packed)); > > = > > Is this a hardware data structure? If not, you shouldn't pack it > > because the first word is only 32 bits and consequently all following > > ones are unaligned. > = > It's a hardware structure. Guess the unaligned u64s were generated when > this structure was extended to support 64bit. > But of course we shouldn't put an atomic_t in a hardware structure, since > it's implementation might change. Not sure about that point. If you need to do atomic operations on the first 32 bits, you shouldn't need to invent your own abstractions for those, and it's highly unlikely that the implementation of atomic_t changes. Arnd <>< ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/