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

Michael H. Warfield mhw at WittsEnd.com
Wed Jan 9 14:33:11 UTC 2013


On Wed, 2013-01-09 at 08:25 -0600, Serge Hallyn wrote:
> Quoting Michael H. Warfield (mhw at WittsEnd.com):
> > 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.

> Also sounds like the manpages could stand to have some more info.

That's already on my ToDo list but probably won't make the straw-man
patch.  The autodev hook will have to be added as well as explanation of
the environment variables.  I always figure that, if I write it, I damn
well better document it.  :-P

Another thing I'm unsure of is that some of this shows up in
lxc-ephemeral(.in) and lxccontainer.c.  I'm not quite sure how those
come into play and haven't touched those at all.

> > 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.  :-)=)

> Great, thanks, that sounds good.

> -serge

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!
-------------- 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/0440469e/attachment.pgp>


More information about the lxc-devel mailing list