From: "Randy.Dunlap" <rdunlap@xenotime.net>
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: serue@us.ibm.com, linux-kernel@vger.kernel.org, dev@sw.ru,
herbert@13thfloor.at, devel@openvz.org, sam@vilain.net,
ebiederm@xmission.com, xemul@sw.ru, haveblue@us.ibm.com,
akpm@osdl.org, clg@fr.ibm.com
Subject: Re: [PATCH 4/9] namespaces: utsname: switch to using uts namespaces
Date: Thu, 18 May 2006 19:45:01 -0700 [thread overview]
Message-ID: <20060518194501.570e1fdb.rdunlap@xenotime.net> (raw)
In-Reply-To: <20060519022114.GB19373@sergelap.austin.ibm.com>
On Thu, 18 May 2006 21:21:14 -0500 Serge E. Hallyn wrote:
> Quoting Randy.Dunlap (rdunlap@xenotime.net):
> > > --- a/arch/i386/kernel/sys_i386.c
> > > +++ b/arch/i386/kernel/sys_i386.c
> > > @@ -210,7 +210,7 @@ asmlinkage int sys_uname(struct old_utsn
> > > if (!name)
> > > return -EFAULT;
> > > down_read(&uts_sem);
> > > - err=copy_to_user(name, &system_utsname, sizeof (*name));
> > > + err=copy_to_user(name, utsname(), sizeof (*name));
> >
> > It would be really nice if you would fix spacing while you are here,
> > like a space a each side of '='.
> >
> > and a space after ',' in the function calls below.
>
> Ok. Then in blocks like the following:
>
> > > - error = __copy_to_user(&name->sysname,&system_utsname.sysname,__OLD_UTS_LEN);
> > > + error = __copy_to_user(&name->sysname,&utsname()->sysname,__OLD_UTS_LEN);
> > > error |= __put_user(0,name->sysname+__OLD_UTS_LEN);
> > > - error |= __copy_to_user(&name->nodename,&system_utsname.nodename,__OLD_UTS_LEN);
> > > + error |= __copy_to_user(&name->nodename,&utsname()->nodename,__OLD_UTS_LEN);
> > > error |= __put_user(0,name->nodename+__OLD_UTS_LEN);
> > > - error |= __copy_to_user(&name->release,&system_utsname.release,__OLD_UTS_LEN);
> > > + error |= __copy_to_user(&name->release,&utsname()->release,__OLD_UTS_LEN);
> > > error |= __put_user(0,name->release+__OLD_UTS_LEN);
> > > - error |= __copy_to_user(&name->version,&system_utsname.version,__OLD_UTS_LEN);
> > > + error |= __copy_to_user(&name->version,&utsname()->version,__OLD_UTS_LEN);
> > > error |= __put_user(0,name->version+__OLD_UTS_LEN);
> > > - error |= __copy_to_user(&name->machine,&system_utsname.machine,__OLD_UTS_LEN);
> > > + error |= __copy_to_user(&name->machine,&utsname()->machine,__OLD_UTS_LEN);
> > > error |= __put_user(0,name->machine+__OLD_UTS_LEN);
>
> Should I leave it as is, to keep the consistent look? Change just the
> lines I'm editing, making it inconsistent? Or change the whole block,
> making my patch seem a bit larger than it really is, but giving the
> nicest end result?
I'd go for the latter, along with my other comment of breaking them
to fit into 80 columns also.
> I suppose I could insert a separate patchset fixing up the spacing in
> those blocks but making no real changes at all, then apply my patch on
> top of that...?
>
> > > --- a/arch/mips/kernel/syscall.c
> > > +++ b/arch/mips/kernel/syscall.c
> > > @@ -232,7 +232,7 @@ out:
> > > */
> > > asmlinkage int sys_uname(struct old_utsname __user * name)
> > > {
> > > - if (name && !copy_to_user(name, &system_utsname, sizeof (*name)))
> > > + if (name && !copy_to_user(name, utsname(), sizeof (*name)))
> >
> >
> > OK, here's my big comment/question. I want to see <nodename> increased to
> > 256 bytes (per current POSIX), so each field of struct <variant>_utsname
> > needs be copied individually (I think) instead of doing a single
> > struct copy.
> >
> > I've been working on this for the past few weeks (among other
> > things). Sorry about the timing.
> > I could send patches for this against mainline in a few days,
> > but I'll be glad to listen to how it would be easiest for all of us
> > to handle.
> >
> > I'm probably a little over half done with my patches.
> > They will end up adding a lib/utsname.c that has functions for:
> > put_oldold_unmame() // to user
> > put_old_uname() // to user
> > put_new_uname() // to user
> > put_posix_uname() // to user
>
> Ok, so long as these functions accept a utsname, we should be able to
> just change what we pass in to these functions to being the namespace's
> utsname, right? Or am I missing the really nasty part?
The nodename field changes from 65 chars (struct new_utsname) to 256 chars
(struct posix_utsname), and nodename is not the final field in the
struct, so it's no longer safe to do a simple struct copy. Each
field in the struct needs to be copied individually if the target is
not a struct posix_utsname. It's not rocket science.
---
~Randy
next prev parent reply other threads:[~2006-05-19 2:42 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-18 15:47 [PATCH 0/9] namespaces: Introduction Serge E. Hallyn
2006-05-18 15:48 ` [PATCH 1/9] namespaces: add nsproxy Serge E. Hallyn
2006-05-21 23:30 ` Sam Vilain
2006-05-21 23:38 ` Eric W. Biederman
2006-05-22 12:39 ` Serge E. Hallyn
2006-05-18 15:49 ` [PATCH 2/9] namespaces: incorporate fs namespace into nsproxy Serge E. Hallyn
2006-05-18 15:49 ` [PATCH 3/9] namespaces: utsname: introduce temporary helpers Serge E. Hallyn
2006-05-18 15:49 ` [PATCH 4/9] namespaces: utsname: switch to using uts namespaces Serge E. Hallyn
2006-05-19 0:02 ` Randy.Dunlap
2006-05-19 2:21 ` Serge E. Hallyn
2006-05-19 2:45 ` Randy.Dunlap [this message]
2006-05-19 3:12 ` Sam Vilain
2006-05-19 9:05 ` Eric W. Biederman
2006-05-19 17:39 ` Randy.Dunlap
2006-05-19 11:58 ` Eric W. Biederman
2006-05-22 19:43 ` Cedric Le Goater
2006-05-22 20:19 ` Randy.Dunlap
2006-05-22 0:19 ` Sam Vilain
2006-05-18 15:49 ` [PATCH 5/9] namespaces: utsname: use init_utsname when appropriate Serge E. Hallyn
2006-05-18 15:50 ` [PATCH 6/9] namespaces: utsname: implement utsname namespaces Serge E. Hallyn
2006-05-18 15:50 ` [PATCH 7/9] namespaces: utsname: sysctl hack Serge E. Hallyn
2006-05-18 15:50 ` [PATCH 8/9] namespaces: utsname: remove system_utsname Serge E. Hallyn
2006-05-18 23:03 ` Paul Mackerras
2006-05-18 23:04 ` Paul Mackerras
2006-05-18 15:51 ` [PATCH 9/9] namespaces: utsname: implement CLONE_NEWUTS flag Serge E. Hallyn
2006-05-18 17:34 ` [PATCH 0/9] namespaces: Introduction Andrew Morton
2006-05-18 19:23 ` John Kelly
2006-05-18 23:28 ` Sam Vilain
2006-05-18 23:43 ` Sam Vilain
2006-05-19 4:24 ` Paul Jackson
2006-05-19 9:23 ` Eric W. Biederman
2006-05-19 11:41 ` Eric W. Biederman
2006-05-19 17:52 ` Jeff Dike
2006-05-20 0:16 ` Sam Vilain
2006-05-19 12:42 ` Herbert Poetzl
2006-05-19 15:13 ` Andrew Morton
2006-05-19 16:27 ` Eric W. Biederman
2006-05-19 16:40 ` Andrew Morton
2006-05-19 17:15 ` Stephen Hemminger
2006-05-19 20:17 ` Dave Hansen
2006-05-19 20:52 ` Alexey Kuznetsov
2006-05-19 18:28 ` Hua Zhong
2006-05-19 19:38 ` Serge E. Hallyn
2006-05-19 19:45 ` John Kelly
2006-05-19 20:23 ` John Kelly
2006-05-19 20:04 ` Dave Hansen
2006-05-20 3:18 ` Eric W. Biederman
2006-05-21 0:48 ` Eric W. Biederman
2006-05-21 22:57 ` Pavel Machek
2006-05-21 23:18 ` Eric W. Biederman
2006-05-21 23:32 ` Herbert Poetzl
2006-05-22 16:54 ` Eric W. Biederman
2006-05-19 13:47 ` Andrey Savochkin
2006-05-19 15:25 ` Andrew Morton
2006-05-20 21:24 ` Herbert Poetzl
2006-05-22 17:23 ` Eric W. Biederman
2006-05-20 0:16 ` Sam Vilain
2006-05-19 8:50 ` Eric W. Biederman
2006-05-19 13:30 ` Serge E. Hallyn
2006-05-21 16:27 ` Serge E. Hallyn
2006-05-21 18:08 ` Eric W. Biederman
2006-05-22 12:10 ` Serge E. Hallyn
2006-05-22 16:44 ` Eric W. Biederman
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=20060518194501.570e1fdb.rdunlap@xenotime.net \
--to=rdunlap@xenotime.net \
--cc=akpm@osdl.org \
--cc=clg@fr.ibm.com \
--cc=dev@sw.ru \
--cc=devel@openvz.org \
--cc=ebiederm@xmission.com \
--cc=haveblue@us.ibm.com \
--cc=herbert@13thfloor.at \
--cc=linux-kernel@vger.kernel.org \
--cc=sam@vilain.net \
--cc=serue@us.ibm.com \
--cc=xemul@sw.ru \
/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®