From: Pavel Machek <pavel@ucw.cz>
To: Dave Hansen <haveblue@us.ibm.com>
Cc: Cedric Le Goater <clg@fr.ibm.com>,
Linux Containers <containers@lists.osdl.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Pavel Emelyanov <xemul@openvz.org>
Subject: Re: [PATCH 1/2] Extend sys_clone and sys_unshare system calls API
Date: Thu, 24 Jan 2008 18:50:33 +0100 [thread overview]
Message-ID: <20080124175033.GB4473@elf.ucw.cz> (raw)
In-Reply-To: <1201196817.8329.44.camel@nimitz.home.sr71.net>
On Thu 2008-01-24 09:46:57, Dave Hansen wrote:
> On Thu, 2008-01-24 at 18:37 +0100, Pavel Machek wrote:
> > > Did we decide not to do something with a variable number of
> > arguments?
> > >
> > > sys_clonefoo(unsigned long *flags, int len);
> >
> > That is evil, because that means strace can no longer reliably print
> > flags being used (for example).
>
> Ahhh. Just like it can't print strings for "buf"?
>
> write(int fd, char *buf, size_t len)
>
> Man, strace is stupid! ;)
I said _reliably_.
Guess what happens on smp when one process will periodically overwrite
buf, and second will do the syscall?
It sucks for write, but it would suck much more for clone, where flags
drastically change the behaviour.
(Yep, it is possible to do reliably, see subterfugue, but it is a lot
of work and lot of overhead).
> If that's *really* a concern, why don't we just pass, say 4 or 5 longs
> in:
>
> sys_clonebig(unsigned long flags0, unsigned long flags1,
> unsigned long flags2, unsigned long flags3);
Works for me.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
prev parent reply other threads:[~2008-01-24 17:50 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-16 12:58 Pavel Emelyanov
2008-01-16 13:00 ` [PATCH 2/2] Propagate the long_clone_arg up to the create_new_namespaces Pavel Emelyanov
2008-01-16 14:23 ` [PATCH 1/2] Extend sys_clone and sys_unshare system calls API Jonathan Corbet
2008-01-16 15:05 ` Pavel Emelyanov
2008-01-17 3:48 ` Al Viro
2008-01-17 9:28 ` Cedric Le Goater
2008-01-17 15:02 ` Extending syscalls (was: [PATCH 1/2] Extend sys_clone and sys_unshare system calls API) Jonathan Corbet
2008-01-17 19:26 ` Extending syscalls H. Peter Anvin
2008-01-23 20:59 ` [PATCH 1/2] Extend sys_clone and sys_unshare system calls API Pavel Machek
2008-01-24 17:09 ` Cedric Le Goater
2008-01-24 17:24 ` Dave Hansen
2008-01-24 17:37 ` Pavel Machek
2008-01-24 17:46 ` Dave Hansen
2008-01-24 17:50 ` Pavel Machek [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=20080124175033.GB4473@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=akpm@linux-foundation.org \
--cc=clg@fr.ibm.com \
--cc=containers@lists.osdl.org \
--cc=haveblue@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=xemul@openvz.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®