[lxc-devel] [PATCH] Remove MAKEDEV call, add autodev hooks, add environment variables for hook scripts.

Michael H. Warfield mhw at WittsEnd.com
Fri Jan 11 16:02:32 UTC 2013


On Thu, 2013-01-10 at 16:52 -0600, Serge Hallyn wrote:
> Quoting Michael H. Warfield (mhw at WittsEnd.com):
> 
> looks good, one comment (a "you were right" :)

:-)=)

[[ Snip ]]

> Sorry - definately the scripts don't need to know LXC_LOGPATH.  That's
> only to keep track (in memory) of the logfile that was stored in the
> rcfile in case it was override with -o in lxc_start.  So actually you're
> right, I think we should get rid of that variable, just use it (or not)
> when we see it.  I was thinking we might want to store it in some cases
> for the api - but then if we're using lxc-start we're not using the api,
> and we only override at lxc-start.  So no sense storing this.

Ok...  Concur on the file name / path.  Pretty much what I was thinking
but I had to be sure.  I'll pull that from the code then and, if that's
the only comment, I'll sign off on a final version shortly and send my
patch back in.

Now...  I do think the "loglevel" / "priority" could still be valuable,
especially if it's variable ala a signal or such as some persistent
commands do.  Whether it's from a signal, an API, the config file, or
the command line, it could still be useful, for debugging purposes, for
a hook script to know what the logging (or verbosity) level is.  I would
like to see those welded together.

I would probably also leave it there as a template in case someone finds
yet another "int" config variable they want to export to a script
(although, that's why I wanted to include the rcfile - so that scripts
could go back and paw through the config file for other things).  (I'm
more than happy when other people plagerize my code for their tasks.)
Especially for the autodev hook, I can see where a script might want to
know the number of consoles or ptys or allowed devices, but that's way
more than I can predict at this time.

That (the whole logfile path issue) raises another question, though, in
my mind.  Where does stdout and stderr from the hook scripts go?  I'm
going to retest but I don't recall ever seeing the simple (stdout)
output from some of my earlier test scripts.  I'll retest that under
controlled conditions and see where fd 1 and 2 output to from a hook
script when I have everything separated.  IAC, that's an orthogonal
issue to the primary mission of this patch, so I'm going to put a bow on
it.

ITMT, I'll make that minor change and send in the patch.

Thanks!

-- 
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/20130111/95dd63ec/attachment.pgp>


More information about the lxc-devel mailing list