All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: John Calixto <john.calixto@modsystems.com>
Cc: linux-mmc@vger.kernel.org, cjb@laptop.org
Subject: Re: [PATCH resend] mmc: Added ioctl to let userspace apps send ACMDs
Date: Sat, 19 Mar 2011 10:42:30 +0100	[thread overview]
Message-ID: <201103191042.30718.arnd@arndb.de> (raw)
In-Reply-To: <alpine.DEB.2.00.1103181706450.6084@peruna>

On Saturday 19 March 2011, John Calixto wrote:

> > > -static int mmc_app_cmd(struct mmc_host *host, struct mmc_card *card)
> > > +int mmc_app_cmd(struct mmc_host *host, struct mmc_card *card)
> > >  {
> > >         int err;
> > >         struct mmc_command cmd;
> > > @@ -48,6 +48,7 @@ static int mmc_app_cmd(struct mmc_host *host, struct mmc_card *card)
> > >
> > >         return 0;
> > >  }
> > > +EXPORT_SYMBOL(mmc_app_cmd);
> >
> > Why not EXPORT_SYMBOL_GPL?
> >
> 
> I was just using the convention already used in sd_ops.c.  I can send a
> pre-patch that sets all of the symbol exports in that file to be
> EXPORT_SYMBOL_GPL, but without confirmation from you and others on this
> list, that seems like overstepping my "jurisdiction".  Is that preferable?

No, you shouldn't change existing symbols, we normally don't do that.
Some subsystems in the kernel generally allow regular EXPORT_SYMBOL
for everything, I don't know if that's the case here.

Chris, do you prefer to leave the new export as EXPORT_SYMBOL
along wiht the others or to use EXPORT_SYMBOL_GPL?

> > As I mentioned, any ioctl command that gets introduced needs to be
> > designed very carefully to make sure we don't need to change it in the
> > future. The only two things I can see here are:
> >
> > * The struct_version should be removed
> > * The data pointer is not compatible between 32 and 64 bits.
> >   One solution for this would be to make it a __u64 argument
> >   and require the user to cast the pointer to a 64 bit type.
> 
> I don't understand your comment about the data pointer not being
> compatible between 32 and 64 bits.  Wouldn't the compiler take care of
> pointer size?

The problem is when you have a 64 bit kernel that can run both
32 and 64 bit user applications. The compiler for the 32 bit user
process will create a smaller data structure than what a 64 bit
kernel expects. The two options here are to force the compiler
to use a compatible layout, or to use the compat_ioctl() function
to convert from one format to the other.

	Arnd

  reply	other threads:[~2011-03-19  9:42 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-17 18:28 [PATCH resend] mmc: Added ioctl to let userspace apps send ACMDs John Calixto
2011-03-17 18:35 ` Ben Dooks
2011-03-17 21:55 ` Arnd Bergmann
2011-03-18 17:32   ` John Calixto
2011-03-18 17:56     ` Michał Mirosław
2011-03-18 19:26       ` Arnd Bergmann
2011-03-19 17:36         ` Michał Mirosław
2011-03-19 19:00           ` Arnd Bergmann
2011-03-21 18:37           ` John Calixto
2011-03-21 23:16             ` Michał Mirosław
2011-03-22 22:31               ` John Calixto
2011-03-23  0:18                 ` Michał Mirosław
2011-03-23  0:44                   ` John Calixto
2011-03-23  7:57                     ` Arnd Bergmann
2011-03-18 19:25     ` Arnd Bergmann
2011-03-18 22:06       ` [PATCH resend] mmc: Added ioctl to let userspace apps send ACMD John Calixto
2011-03-19 11:52         ` Arnd Bergmann
2011-03-20  2:12           ` John Calixto
2011-03-20  5:11             ` Michał Mirosław
2011-03-21 12:25               ` Arnd Bergmann
2011-03-21 14:26                 ` Andrei Warkentin
2011-03-21 18:22                   ` John Calixto
2011-03-19  0:24   ` [PATCH resend] mmc: Added ioctl to let userspace apps send ACMDs John Calixto
2011-03-19  9:42     ` Arnd Bergmann [this message]
2011-03-19 16:09       ` Chris Ball

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=201103191042.30718.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=cjb@laptop.org \
    --cc=john.calixto@modsystems.com \
    --cc=linux-mmc@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.