?

Log in

The Conversation Pit - Back from a week in Moscow. [entries|archive|friends|userinfo]
Rob Landley

[ website | My Website ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Back from a week in Moscow. [Apr. 5th, 2011|08:05 am]
Rob Landley
[Tags|]
[Current Location |Einstein's]
[mood |chipperchipper]

So I got my NFSv3 containerization patches submitted. There are three of them for the basic network namespace support for NFSv3 in what's probably correct approach. So far, nobody's cared to comment on them (even the people who were interested in the topic before, who I cc'd on the submission), although I tracked some down on skype and they promised to bump review up on their todo list.

Today, in theory I'm containerizing lockd (and statd, both of which are a horrible incestuous nightmare which is probably going to require one instance per container). In practice, I got distracted reading the LXC source code. It's... very verbose for what it does.


For example, it has "templates" which are shell scripts that create root filesystems. It's got a directory full of these. It _also_ has a lxc-create script which is 175 lines long and boils down to:

${templatedir}/lxc-$lxc_template --path=$lxc_path/$lxc_name \
--name=$lxc_name

That's 175 lines of boilerplate and redundant options parsing for a ONE LINE wrapper around whichever template script you've selected.

lxc-destroy is similar, it's 79 lines of wrapper around:

rm -rf --preserve-root $lxc_path/$lxc_name

As for lxc-netstate: I'm going to assume that doing a bind mount on /proc/self/net won't leak resources when that /proc directory goes away, but honestly that strikes me as really dodgy behavior. And the $cgroup_path logic won't work for directories with spaces in the name, so "don't do that then" I guess.

By the way, ever lxc command requires the name of the container it's operating on. And it specifies it with "-n". But it's not an optional argument. Imagine if "rm filename" was actually "rm -n filename". What's the -n for?

Also, there's no reason lxc containers have to live in /some/random/path. You might as well go "lxc-create thingy" and have it create a "thingy" directory in the current directory, and then "lxc-start thingy" to launch it. If you want a path, supply a path. Whoever came up with the UI for this went out of their WAY to make it brittle.

As for the source code... error.h contains a single function prototype. It's 28 lines long. For some reason there's javadoc explanations of the functions in the .h files, with the function prototypes, not with the actual function definitions. It has 186 lines of (unnecessary) logging infrastructure in log.c, and the corresponding header file is _294_ lines long.

Right, the functions implemented in C are: attach, unshare, stop, start, execute, monitor, wait, console, freeze, info, cgroup, unfreeze, checkpoint, restart, and kill. Each has a corresponding C file, I should go read those...
linkReply

Comments:
From: hoduhilo
2011-04-08 01:58 pm (UTC)
Love your site man keep up the good work

(Reply) (Thread)