All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serue@us.ibm.com>
To: Tejun Heo <tj@kernel.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	Greg KH <greg@kroah.com>, Al Viro <viro@ZenIV.linux.org.uk>,
	Benjamin Thery <benjamin.thery@bull.net>,
	linux-kernel@vger.kernel.org, Al Viro <viro@ftp.linux.org.uk>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: sysfs: tagged directories not merged completely yet
Date: Tue, 14 Oct 2008 13:53:20 -0500	[thread overview]
Message-ID: <20081014185320.GA24908@us.ibm.com> (raw)
In-Reply-To: <48F45075.7000003@kernel.org>

Quoting Tejun Heo (tj@kernel.org):
> >> Can somebody hammer the big picture regarding namespaces into my
> >> small head?
> > 
> > 100,000 foot view.  A namespace introduces a scope so multiple
> > objects can have the same name.  Like network devices.
> > 
> > 10,000 foot view.  The network namespace looks to user space
> > as if the kernel has multiple independent network stacks.
> > 
> > 1000 foot view.  I have two network devices named lo, and sysfs
> > does not currently have a place for me to put them.
> > 
> > Leakage and being able to fool an application that it has the entire
> > kernel to itself are not concerns.  The goal is simply to get the
> > entire object name to object translation boundary and the namespace
> > work is done.  We have largely achieved, and the code to do
> > so once complete is reasonable enough that it should be no
> > worse than dealing with any other kernel bug.
> 
> Yes, I'm aware of the goals.  What I'm curious about is the consensus
> regarding network namespace and all its implications.  It adds a lot
> of complexities over a lot of places.  e.g. following the sysfs code
> becomes quite a bit more difficult after the namespace changes (maybe
> it's just me but still).  So, I was asking whether people generally
> agree that having the namespace thing is worth the added complexities.
> 
> I think it serves pretty small group of users.  Hosting service

I don't think that's true.

Let's say i want to run debootstrap and set up a minimal image
to run postfix.  Now if I want to run that on my laptop as its own
minimal separate machine, I need to run qemu or kvm.  That's huge.

Once we finally get network namespaces(-sysfs) finished, I can set up a
10-line config file, download and install
https://sourceforge.net/projects/lxc/, run

	lxc-execute -n postfix-cont /bin/bash

and voila, I have postfix running as though on a separate machine,
but with none of the kvm/qemu overhead.  Which means that instead
of being able to do one at a time, i can do... hundreds?  So I
think this is something everyone will find useful - but of course
I *am* biased :)

> providers and people trying to migrate processes from one machine to
> another, both of which can be served pretty well with virtualization.
> It does have higher overhead both processing power and memory wise but
> IIUC the former is being actively worked on w/ new processor features
> like nested paging tables and all and memory is really cheap these
> days, so I'm a bit skeptical how much this is needed and how much we
> should pay for it.
> 
> Another venue to explore is whether the partial view of proc and sysfs
> can be implemented in less pervasive way.  Implementing it via FUSE
> might not be easier per-se but I think it would be better to do it

Again fuse doesn't address the *core* issue (sysfs needing a way to
create files for multiple devicenames with same name).  But I believe
Benjamin was looking into a minimal patch to fix that.  Benjamin,
have you gotten anywhere with that?

> that way if we can instead of adding complexities to both proc and
> sysfs.
> 
> One last thing that came to mind is, how would uevents be handled?
> ie. what happens if a network card which is presented as ethN in the
> namespace goes away?  How does the system deal with it?
> 
> Thanks.
> 
> -- 
> tejun

  parent reply	other threads:[~2008-10-14 18:53 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-22 14:31 sysfs: tagged directories not merged completely yet Benjamin Thery
2008-09-22 15:34 ` Greg KH
2008-09-22 20:24   ` Eric W. Biederman
2008-09-23 14:24   ` Benjamin Thery
2008-09-23 18:23     ` Eric W. Biederman
2008-10-03 10:13       ` Al Viro
2008-10-05  5:32         ` Greg KH
2008-10-07  8:27           ` Eric W. Biederman
2008-10-07 10:47             ` [PATCH 0/3] minor sysfs tagged directory fixes Eric W. Biederman
2008-10-07 10:49               ` [PATCH 1/3] sysfs: Remove lock ordering violation in sysfs_chmod_file Eric W. Biederman
2008-10-07 10:51                 ` [PATCH 2/3] sysfs: Fix and sysfs_mv_dir by using lock_rename Eric W. Biederman
2008-10-07 10:52                   ` [PATCH 3/3] sysfs: Take sysfs_mutex when fetching the root inode Eric W. Biederman
2008-10-07 21:21                   ` [PATCH 2/3] sysfs: Fix and sysfs_mv_dir by using lock_rename Dave Hansen
2008-10-07 21:19                 ` [PATCH 1/3] sysfs: Remove lock ordering violation in sysfs_chmod_file Dave Hansen
2008-10-07 22:31                   ` Eric W. Biederman
2008-10-07 22:27             ` sysfs: tagged directories not merged completely yet Greg KH
2008-10-07 22:54               ` Serge E. Hallyn
2008-10-07 23:39                 ` Greg KH
2008-10-08  0:12                   ` Serge E. Hallyn
2008-10-08  0:38                     ` Greg KH
2008-10-08 14:18                       ` Serge E. Hallyn
2008-10-07 23:34               ` Tejun Heo
2008-10-14  1:11                 ` Eric W. Biederman
2008-10-14  7:55                   ` Tejun Heo
2008-10-14 12:19                     ` Eric W. Biederman
2008-10-15 11:04                       ` Tejun Heo
2008-10-16 21:58                         ` Eric W. Biederman
2008-10-14 18:53                     ` Serge E. Hallyn [this message]
2008-10-15  0:48                       ` Eric W. Biederman
2008-10-15 13:42                         ` Serge E. Hallyn
2008-10-15 13:54                           ` Benjamin Thery
2008-10-08  0:39               ` Eric W. Biederman
2008-10-08  1:29               ` Eric W. Biederman
2008-10-07  8:08         ` Eric W. Biederman
2008-10-07  9:01         ` Daniel Lezcano
2008-10-07  9:12         ` Tejun Heo
2008-10-07 11:56           ` Eric W. Biederman
2008-10-07 12:19             ` Tejun Heo
2008-10-07 23:17               ` Tejun Heo
2008-10-08  0:04                 ` Eric W. Biederman
2008-10-08  0:20                   ` Tejun Heo
2008-10-08  0:58                     ` 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=20081014185320.GA24908@us.ibm.com \
    --to=serue@us.ibm.com \
    --cc=benjamin.thery@bull.net \
    --cc=ebiederm@xmission.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tj@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@ZenIV.linux.org.uk \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.