public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ulrich Drepper <drepper@redhat.com>
To: Eric Dumazet <dada1@cosmosbay.com>
Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
	mingo@elte.hu, tglx@linutronix.de, torvalds@linux-foundation.org
Subject: Re: [PATCHv3 0/4] sys_indirect system call
Date: Mon, 19 Nov 2007 07:12:29 -0800	[thread overview]
Message-ID: <4741A7DD.1030407@redhat.com> (raw)
In-Reply-To: <20071119145224.31ee5242.dada1@cosmosbay.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eric Dumazet wrote:
>>   union indirect_params i;
>>   i.file_flags.flags = O_CLOEXEC;
> 
> This setup forbids future addons to file_flags
> 
> In three years, when we want to add a new indirect feature to socket() 
> call, do we need a new indirect2() syscall ?

No, it doesn't.  The setup is indefinitely expandable.

All you need to do, if it becomes necessary to have more than an int, is
to define a little structure for the system call and then use it.  The
only requirement is that the code has to assume a value of zero is what
is used today.  That's the whole point.

union indirect_params {
  struct {
    int flags;
  } file_flags;
  struct {
    int flags;
    int new_syscall_data1;
    sigset_t and_a_sigmask;
  } new_data;
};

Old programs will set only the 'flags' member of 'new_data' while new
once can also set the new elements.  New programs on old kernels will
eithe have failing calls since the structure is too big or the call will
not have all the desired effects.  The latter can be tested for.


> Or better, you could avoid using 'union indirect_params' in user code, and 
> only use the substructs for each function.

There is no overhead introduced through the union.  The only reason the
union is there in the first place is to allocate sufficient data in
task_struct to cover all cases.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHQafd2ijCOnn/RHQRAlSFAJ99lahwCDZGRSlIHCov5bWowrpoiQCgwvW4
LDSEusNUpMfIE1ywBCRDBfc=
=ChVT
-----END PGP SIGNATURE-----

  reply	other threads:[~2007-11-19 15:13 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-17  5:31 [PATCHv3 0/4] sys_indirect system call Ulrich Drepper
2007-11-18  7:44 ` H. Peter Anvin
2007-11-18  9:36   ` Ulrich Drepper
2007-11-18 19:37     ` H. Peter Anvin
2007-11-20  3:28       ` Ulrich Drepper
2007-11-20  4:27         ` H. Peter Anvin
2007-11-19 13:52 ` Eric Dumazet
2007-11-19 15:12   ` Ulrich Drepper [this message]
2007-11-19 15:43     ` Eric Dumazet
2007-11-19 15:48       ` Ulrich Drepper
2007-11-19 16:14         ` Eric Dumazet
2007-11-19 19:08           ` Ingo Molnar
2007-11-20 14:11             ` dean gaudet
2007-11-20 16:16               ` Ulrich Drepper

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=4741A7DD.1030407@redhat.com \
    --to=drepper@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=dada1@cosmosbay.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --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