Quoting Michael H. Warfield (m...@wittsend.com): > On Wed, 2013-01-09 at 21:27 +0800, Alexander Vladimirov wrote: > > 2013/1/9 Michael H. Warfield <m...@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.hal...@canonical.com>: > > >> > > Quoting Michael H. Warfield (m...@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. > 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 ------------------------------------------------------------------------------ Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
