public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: JANAK DESAI <janak@us.ibm.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Al Viro <viro@ftp.linux.org.uk>,
	chrisw@osdl.org, dwmw2@infradead.org, jamie@shareable.org,
	serue@us.ibm.com, linuxram@us.ibm.com, jmorris@namei.org,
	sds@tycho.nsa.gov, akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH -mm 1/5] New system call, unshare
Date: Fri, 09 Dec 2005 14:57:08 -0500	[thread overview]
Message-ID: <4399E194.3080105@us.ibm.com> (raw)
In-Reply-To: <20051209190137.GA25656@elte.hu>

Ingo Molnar wrote:

>* JANAK DESAI <janak@us.ibm.com> wrote:
>
>  
>
>>To answer Ingo's question, we did look at other flags when I started.  
>>However, I wanted to keep the system call simple enough, with atleast 
>>namespace unsharing, so it would get accepted. In the original 
>>discussion on fsdevel, unsharing of vm was mentioned as useful so I 
>>added that in addition to namespace unsharing.
>>    
>>
>
>i think the only sane way to do this is to support unsharing for all 
>flags. Internally (i.e. in the patch-queue) it can still be structured 
>in a finegrained way, but in terms of exposing it to applications, it 
>should be an all or nothing solution i think.
>
>	Ingo
>
>
>  
>
yes, I understand that now. I am currently restructuring the code based 
on Al Viro's
post. The system call will ..
    * accept all flags
    * check for illiegal combination of flags and return -EINVAL
    * check for implied missing flags and silently force them
    * for each flag, call a corresponding unshare function. The flag 
specific unshare function will
       * return -EINVAL if the structure is being shared but the 
corresponding unsharing code is not
         implemented yet
       * return success and pass back a pointer to a newly allocated and 
duplicated structure if the
         structure is being shared and the unshare code is implemented 
for that flag
       * return success and pass back a null pointer if the structure is 
not being shared to begin with
       * return -ENOMEM or appropriate error if there is a failure in 
allocating/duplicating the structure
    * Error returns will appropriately cleanup previously duplicated 
structures and return with an error
      from the syscall
    * If no errors, then after going through all flags, we will be left 
with appropriate new structures.
    * acquire appropriate (task_lock) locks and update current task 
struct with non-null, duplicated,
      structures
    * relinquish locks and return success from the syscall

This will allow us to incrementally add unshare functionality for 
different flags without requiring
and changes to apps.

Please let me know if you see any gotchas in the above.

-Janak



      reply	other threads:[~2005-12-09 19:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-08 22:09 [PATCH -mm 1/5] New system call, unshare JANAK DESAI
2005-12-09 10:55 ` Ingo Molnar
2005-12-09 12:02   ` Al Viro
2005-12-09 14:15     ` JANAK DESAI
2005-12-09 14:34       ` Al Viro
2005-12-09 14:48         ` JANAK DESAI
2005-12-09 19:01       ` Ingo Molnar
2005-12-09 19:57         ` JANAK DESAI [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=4399E194.3080105@us.ibm.com \
    --to=janak@us.ibm.com \
    --cc=akpm@osdl.org \
    --cc=chrisw@osdl.org \
    --cc=dwmw2@infradead.org \
    --cc=jamie@shareable.org \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxram@us.ibm.com \
    --cc=mingo@elte.hu \
    --cc=sds@tycho.nsa.gov \
    --cc=serue@us.ibm.com \
    --cc=viro@ftp.linux.org.uk \
    /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