public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
To: Heiko Carstens <heiko.carstens-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
	cborntra-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org,
	schwidefsky-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org
Subject: Re: [PATCH/RFC 2/2] s390 virtualization interface.
Date: Tue, 1 May 2007 23:12:11 +0200	[thread overview]
Message-ID: <200705012312.11692.arnd@arndb.de> (raw)
In-Reply-To: <20070429080039.GA8332-5VkHqLvV2o3MbYB6QlFGEg@public.gmane.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 {
> > > +   atomic_t scn;
> > > +   __u64   reserved;
> > > +   __u64   sda;
> > > +   __u64   reserved2[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/

  parent reply	other threads:[~2007-05-01 21:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-27 13:40 [PATCH/RFC 2/2] s390 virtualization interface Carsten Otte
     [not found] ` <1177681235.5770.22.camel-WIxn4w2hgUz3YA32ykw5MLlKpX0K8NHHQQ4Iyu8u01E@public.gmane.org>
2007-04-27 15:23   ` Anthony Liguori
     [not found]     ` <4632155C.8030503-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2007-04-27 15:45       ` Carsten Otte
2007-04-27 16:53   ` Arnd Bergmann
     [not found]     ` <200704271853.41523.arnd-r2nGTMty4D4@public.gmane.org>
2007-04-29  8:00       ` Heiko Carstens
     [not found]         ` <20070429080039.GA8332-5VkHqLvV2o3MbYB6QlFGEg@public.gmane.org>
2007-05-01 21:12           ` Arnd Bergmann [this message]
     [not found]             ` <200705012312.11692.arnd-r2nGTMty4D4@public.gmane.org>
2007-05-02  4:46               ` Avi Kivity
2007-05-02  8:25               ` Christoph Hellwig

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=200705012312.11692.arnd@arndb.de \
    --to=arnd-r2ngtmty4d4@public.gmane.org \
    --cc=cborntra-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org \
    --cc=heiko.carstens-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org \
    --cc=kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=schwidefsky-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox