All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yann Droneaud <ydroneaud@opteya.com>
To: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Cc: "Skidanov, Alexey" <Alexey.Skidanov@amd.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	ydroneaud@opteya.com
Subject: Re: 32 bit user space compatibility
Date: Mon, 03 Nov 2014 13:46:09 +0100	[thread overview]
Message-ID: <1415018769.5491.92.camel@localhost.localdomain> (raw)
In-Reply-To: <20141028223435.73b3778c@alan.etchedpixels.co.uk>

Hi,

Le mardi 28 octobre 2014 à 22:34 +0000, One Thousand Gnomes a écrit :
> On Sun, 26 Oct 2014 12:25:08 +0000
> "Skidanov, Alexey" <Alexey.Skidanov@amd.com> wrote:

>  
> > Running 32 bit user space needs some work to be done with ioctls. I understand that there are two options to implement:
> > 1.       Use only fixed size types. Pad IOCTLS params to multiple of 64 bits - simple; don't know if it covers all compatibility issues; 
> > 2.       32 bit compatibility layer (through compat_ioctl, just like many drivers in kernel implement)  - just a little bit simple code with some translations; really covers all issues;
> >  
> > Which one is preferred by kernel community?
> 
> You shouldn't need to pad paramters in most cases as platform alignment
> rules are usually sane for 32 and 64bit. 

In most case, except i386 (ia32) vs amd64 (x86_64): u64 are going to be
aligned on 4 bytes boundaries for 32bits ABI and 8 bytes boundaries for
64bits ABI.

I've tried to explained this issue in a lightning talk[1][2] I'd given
at Kernel Recipes[3] this year.

[1] http://opteya.com/talks/2014/kernel-recipes/lightning-talk-kernel-userspace-ABI/
[2] https://gitorious.org/opteya/talk-kernel-userspace-abi
[3] http://kernel.recipes/

Regards.

-- 
Yann Droneaud
OPTEYA




      reply	other threads:[~2014-11-03 12:46 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-26 12:25 32 bit user space compatibility Skidanov, Alexey
2014-10-28 22:34 ` One Thousand Gnomes
2014-11-03 12:46   ` Yann Droneaud [this message]

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=1415018769.5491.92.camel@localhost.localdomain \
    --to=ydroneaud@opteya.com \
    --cc=Alexey.Skidanov@amd.com \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.