[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1400270662.3540.32.camel@canyon.ip6.wittsend.com>
Date: Fri, 16 May 2014 16:04:22 -0400
From: "Michael H. Warfield" <mhw@...tsEnd.com>
To: James Bottomley <James.Bottomley@...senPartnership.com>
Cc: "Michael H.Warfield" <mhw@...tsEnd.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Serge Hallyn <serge.hallyn@...ntu.com>,
linux-kernel@...r.kernel.org, Jens Axboe <axboe@...nel.dk>,
Arnd Bergmann <arnd@...db.de>,
Eric Biederman <ebiederm@...ssion.com>,
Serge Hallyn <serge.hallyn@...onical.com>,
lxc-devel@...ts.linuxcontainers.org,
Pavel Emelianov <xemul@...allels.com>
Subject: Re: [lxc-devel] Mount and other notifiers, was: [RFC PATCH 00/11]
Add support for devtmpfs in user namespaces
On Fri, 2014-05-16 at 12:52 -0700, James Bottomley wrote:
> On Fri, 2014-05-16 at 15:42 -0400, Michael H. Warfield wrote:
> > > As an aside (probably requiring a new thread) we were wondering about
> > > some type of notifier on the mount call that we could vector into the
> > > host to perform the action. The main issue for us is mount of procfs,
> > > which really needs to be a bind mount in a container. All of this led
> > > me to speculate that we could use some type of syscall notifier
> > > mechanism to manage capabilities in the host and even intercept and
> > > complete the syscall action within the host rather than having to keep
> > > evolving more an more complex kernel drivers to do this.
> >
> > Interesting. That could be very useful. That might even help with the
> > loop device case where the mounts have to go through loop devices for
> > things like file system images and builds. Very interesting...
> Right, it might even make the loop case go away because now we can
> present a dummy device in the container and when the host sees and
> attempted mount on this, it just projects a bind mount into the
> container and says I've *wink* mounted your "device" for you.
Nice. That idea has prospects. I like the concept.
> This idea is extremely rough, it came from a conversation I had with
> Pavel (cc'd) just before OpenStack about how we might go about
> eliminating our OpenVZ interception of the mount system call which
> currently does all of this in kernel, so we have no code and no proof
> that it's actually feasible (yet).
K. I look forward to hearing more.
I switched from OpenVZ years ago to LXC because OpenVZ was falling too
far behind in kernel support and patches for the leading edge kernels.
At the time, I was working on the MD5 signature code for the Quagga
routing suite for BGP and couldn't maintain my hosts with OpenVZ and
maintain my BGP connections (I have a public ASN and peer on both IPv4
and IPv6) with MD5 signatures at the same time. At the time LXC had
just matured enough to serve my needs. That's interesting to note that
OpenVZ did this by intercepting the mount call. Very interesting...
> James
Regards,
Mike
--
Michael H. Warfield (AI4NB) | (770) 978-7061 | mhw@...tsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
Download attachment "signature.asc" of type "application/pgp-signature" (483 bytes)
Powered by blists - more mailing lists