From: Arnd Bergmann <arnd@arndb.de>
To: Krzysztof Benedyczak <golbi@mat.uni.torun.pl>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] 2/6 POSIX message queues
Date: Sun, 22 Feb 2004 13:23:50 +0100 [thread overview]
Message-ID: <200402221323.50887.arnd@arndb.de> (raw)
In-Reply-To: <Pine.GSO.4.58.0402201848380.10845@Juliusz>
On Friday 20 February 2004 19:11, Krzysztof Benedyczak wrote:
> On Fri, 20 Feb 2004, Arnd Bergmann wrote:
> > Krzysztof Benedyczak wrote:
> > > +
> > > +struct mq_attr {
> > > + long mq_flags; /* message queue flags */
> > > + long mq_maxmsg; /* maximum number of messages */
> > > + long mq_msgsize; /* maximum message size */
> > > + long mq_curmsgs; /* number of messages currently queued */
> > > +};
> > > +
> >
> > Does POSIX mandate that these have to be 'long'? If you can change them
> > all to any of 'int', '__s32' or '__s64', the handlers for 32 bit system
> > call emulation on 64 bit machines will get a lot simpler because the
> > 32 bit user structures are then identical to the 64 bit ones.
>
> Yes, POSIX defines it to longs. And quess that compability issues should
> be handled in kernel?
Yes, compatibility can only be handled in kernel. For each system call
that passes structures with a different layout, you need to do something
like this:
struct compat_mq_attr {
compat_long_t mq_flags;
compat_long_t mq_maxmsg;
compat_long_t mq_msgsize;
compat_long_t mq_curmsgs;
};
asmlinkage long compat_sys_mq_getsetattr(mqd_t mqdes,
const struct compat_mq_attr __user *u_mqstat,
struct compat_mq_attr __user *u_omqstat)
{
struct mq_attr mqstat, omqstat;
mm_segment_t oldfs;
int err, err2;
err = get_user(mqstat.mq_flags, &u_mqstat->mq_flags)
| get_user(mqstat.mq_maxmsg, &u_mqstat->mq_maxmsgs)
| get_user(mqstat.mq_msgsize, &u_mqstat->mq_msgsize)
| get_user(mqstat.mq_curmsgs, &u_mqstat->mq_curmsgs);
if (err)
return -EFAULT;
oldfs = get_fs();
set_fs(KERNEL_DS);
err2 = sys_mq_getsetattr(mqdes, &mqstat, &omqstat);
set_fs(old_fs);
err = get_user(omqstat.mq_flags, &u_omqstat->mq_flags)
| get_user(omqstat.mq_maxmsg, &u_omqstat->mq_maxmsgs)
| get_user(omqstat.mq_msgsize, &u_omqstat->mq_msgsize)
| get_user(omqstat.mq_curmsgs, &u_omqstat->mq_curmsgs);
if (err)
return -EFAULT;
return err2;
}
Nothing difficult here, but slow and avoidable if you have the
structures laid out properly. Normally you can do this with padding,
but that is no good here because 'long' members need sign-extension,
not zero-extension.
Arnd <><
next prev parent reply other threads:[~2004-02-22 12:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-20 13:55 [RFC][PATCH] 2/6 POSIX message queues Arnd Bergmann
2004-02-20 18:11 ` Krzysztof Benedyczak
2004-02-22 12:23 ` Arnd Bergmann [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-02-22 15:12 Manfred Spraul
2004-02-19 14:28 Krzysztof Benedyczak
2004-02-19 14:53 ` Christoph Hellwig
2004-02-19 19:07 ` Sam Ravnborg
2004-02-19 19:44 ` Manfred Spraul
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=200402221323.50887.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=golbi@mat.uni.torun.pl \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox