mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Davide Libenzi <davidel@xmailserver.org>
To: Ulrich Drepper <drepper@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>
Subject: Re: [patch 0/6] sys_indirect RFC - sys_indirect introduction
Date: Sat, 30 Jun 2007 12:23:25 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0706301208140.2957@alien.or.mcafeemobile.com> (raw)
In-Reply-To: <a36005b50706291848p406fbb9aw99697f609b0d5c4b@mail.gmail.com>

On Fri, 29 Jun 2007, Ulrich Drepper wrote:

> On 6/29/07, Davide Libenzi <davidel@xmailserver.org> wrote:
> > [include/linux/indirect.h]
> >         #define SYSIND_CTX_OPENFLAGS    0
> >         struct sysind_ctx_OPENFLAGS {
> >                 __u32 ctx;
> >                 __u32 flags;
> 
> I agree that this interface is more than any other in danger of
> needing an interface change.  But I think your solution is a bit too
> expensive and complex.  You need two reads from userlevel.

But, a __get_user(), once you scrap off all the gcc wrapping, is bacially 
a move. That could even be removed, but really I don't see the reason 
since it allows for a cleaner strcture definition in userland.




> The standard way to handle this is a versioned struct.  I.e., define a
> struct for the current needs, define an initial version.  To use the
> syscall pass the version number and the struct pointer to the syscall.
> If the kernel doesn't know the version number it fails.  Otherwise it
> might have to read old versions of the struct which is trivial to do.
> E.g.:
> 
> #define SYSIND_VERSION 1
> #define SYSIND_CTX_OPENFLAGS 0
> #define SYSIND_CTX_SIGMASK 1
> struct sysind_ctx {
>  int ctx;
>  union {
>    int flags;
>    kernel_sigset_t  sset;
>  };
> };

But this does not allow more than one context to be set at a time, like 
the current implementation does. Ie, the current implementation allow you 
to:

#define SYSIND_CTX_OPENFLAGS    0
struct sysind_ctx_OPENFLAGS {
	__u32 ctx;
	__u32 flags;
};

#define SYSIND_CTX_SIGSET       1
struct sysind_ctx_SIGSET {
	__u32 ctx;
	__compat_sigset set;
};

struct sysind_ctx_OPENFLAGS octx;
struct sysind_ctx_SIGSET sctx;
struct indirect_ctx *ctxs[2];
unsigned long params[6];

octx.ctx = SYSIND_CTX_OPENFLAGS;
octx.flags = O_CLOEXEC;
sctx.ctx = SYSIND_CTX_SIGSET;
sctx.set = SIG_XYZ | SIG_ABC;
ctxs[0] = (struct indirect_ctx *) &octx;
ctxs[1] = (struct indirect_ctx *) &sctx;
params[0] = blah;
params[1] = blew;
...
res = indirect(__NR_xxxx, ctxs, 2, params);


So you basically keep the context strcture separated, and allow to pass 
down more then one context to be set.
Another solution would be to have:

struct sysind_ctx_OPENFLAGS {
	__u32 flags;
};
struct sysind_ctx_SIGSET {
	__compat_sigset set;
};
struct monster_struct {
	__u32 size;
	__u64 flags;
	struct sysind_ctx_OPENFLAGS octx;
	struct sysind_ctx_SIGSET sctx;
	...
};

Where size gives you the size of the monster structure, and every bit on 
flags tells you which strcture inside monster is valid.
But I'd clearly prefer the former.



- Davide



  reply	other threads:[~2007-06-30 19:23 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-29 21:48 Davide Libenzi
2007-06-30  1:48 ` Ulrich Drepper
2007-06-30 19:23   ` Davide Libenzi [this message]
2007-06-30 21:54     ` Ulrich Drepper
2007-06-30 22:27       ` Davide Libenzi
2007-06-30 22:32         ` Davide Libenzi
2007-07-01 16:25           ` Ulrich Drepper
2007-07-01 17:09             ` Davide Libenzi
2007-07-02 14:09               ` Ulrich Drepper
2007-07-02 22:37                 ` Davide Libenzi
2007-07-03  0:28                   ` Ulrich Drepper
2007-07-03  0:37                     ` Davide Libenzi

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=Pine.LNX.4.64.0706301208140.2957@alien.or.mcafeemobile.com \
    --to=davidel@xmailserver.org \
    --cc=akpm@linux-foundation.org \
    --cc=drepper@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=torvalds@linux-foundation.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

all inboxes | Powered by JetHome®