[lxc-devel] [PATCH] Support MS_SHARED / - issues calling MAKEDEV

[Michael H. Warfield]

On Wed, 2013-01-09 at 21:27 +0800, Alexander Vladimirov wrote:
> 2013/1/9 Michael H. Warfield <mhw at wittsend.com>:
> > On Tue, 2013-01-08 at 15:40 -0500, Michael H. Warfield wrote:
> >> On Wed, 2013-01-09 at 04:31 +0800, Alexander Vladimirov wrote:
> >> > Well, properly placed hook could do all the things MAKEDEV supposed to do.
> >>
> >> And would give us the flexibility to worry about things like serial
> >> devices or some USB devices or a few other things that would ordinarily
> >> be populated by udev but don't vary over the life of the container.
> >>
> >> > 2013/1/9 Serge Hallyn <serge.hallyn at canonical.com>:
> >> > > Quoting Michael H. Warfield (mhw at WittsEnd.com):
> >> > >> More on the MAKEDEV debacle...
> >> > > ...
> >> > >> This whole thing with MAKEDEV is looking more and more like a morass
> >> > >> with no way to cleanly resolve it.
> >> > >
> >> > > It sounds like consensus is it should be dropped from staging?
> >
> >> +1 for dropping the call to MAKEDEV, yeah.
> >
> > Looking at the sources now, removing run_makedev() and the call to is is
> > pretty trivial.  I've already got a patch for that.
> >
> > WRT Alexander's suggestion for a hook...  I like that idea but a
> > question comes up.  I've already got a patch for that hook,
> > lxc.hook.autodev, as well and it's very close to where the
> > lxc.hook.mount hooks is located only this one only gets invoked if
> > autodev=1.  I'm still doing some testing but it looks like this could be
> > done with the mount hook if we don't care for an isolated autodev one.
> > OTOH, I can see some value in having a separate hook that only gets
> > called if autodev is enabled.
> >
> > Next thought...  I dawns on me that many of these scripts could use some
> > environment variables, such as the container name, the location of the
> > rootfs, the location of the conf file, etc, etc.  That way, you could
> > make the scripts a little more generic.  Problem is that we clear the
> > environment and set "container=lxc" very early on in the process of
> > starting up lxc-start.  Wouldn't that be just as effective if both where
> > done just before execing the container and giving us the ability to pass
> > environment variables to the hook scripts?  Maybe just AFTER
> > lxc.hook.start?

> Maybe we could just provide some environment configuration option in
> container config to extend basic env with required values?

That's an interesting thought too but probably only applicable to
application containers.  I had thought about that as well.  Right now,
my thought is to allow internally generated environment variables to be
passed only to the hook scripts and be flushed before calling the
container itself.

Moving the clearenv and putenv calls to just after the pre-start hook
would do that plus allow for passing of environment variables from the
invoking process through to the hook scripts (may be useful) but still
flushed before invoking the container proper.

The reason I suggest this is that I now realize my earlier attempts at
using the hook scripts to auto populate the container /dev all failed
because I failed to realize WHERE the rootfs was mounted.  I thought I
needed to access the directory in the path I had specified in the rootfs
config variable when, in fact, I needed to use /usr/lib64/lxc/rootfs
instead.  How is a hook script writer expected to know that without
reading the sources and playing with the code?  That's a problem.

But that's orthogonal with adding environment variables to be passed to
the container itself.  Right now, the only one of any significance for
the full system containers is "container=lxc" which we have hard coded
and init (systemd init at least) flushes its environment so it won't
propagate further.  Application containers may be a different matter I
haven't explored.

It's a simple enough patch just moving where we clear and set the
environment.  I may complete a whole combined patch that removes the
MAKEDEV, adds the autodev hook, and moves the clear and put env calls
shortly and throw it out for comments and attract rocks.  :-)=)

Regards,
Mike

> >> Regards,
> >> Mike
> >
> > Regards,
> > Mike
> > --
> > Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.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!
> 

-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.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!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20130109/63681b91/attachment.pgp>