On Fri, Jan 09, 2015 at 05:04:27PM +0000, Serge Hallyn wrote: > Quoting Stéphane Graber ([email protected]): > > Hello, > > > > So I'm looking into how to rework lxc.autodev to apply properly to all > > the cases we care about: > > - Privileged containers started by root > > - Unprivileged containers started by privileged root > > - Unprivileged containers started by unprivileged root > > - Unprivileged containers started by unprivileged user > > > > My understanding is that autodev currently creates /dev/.lxc and then > > uses one directory per-container+lxc-path-hash under there, creates the > > devices nodes and uses that as the container's /dev. > > > > My question is why the /dev/.lxc directory to begin with, wouldn't > > Ok, after looking back through the code a bit, > > One advantage of the current method is that it doesn't need to use a > tmpfs per container. If the host uses devtmpfs (which most do) > then /dev/.lxc can just be a subdir, otherwise it needs to be the > single tmpfs mount. This ensures that systemd will see a separate > /dev and be happy. > > Another advantage of the current method is that the host can see > the container's /dev more easily. Though I htink the existence > of lxc-device suggests that we're ok. I mainly don't want to do > anything that makes it harder for our eventual implementation of > forwarding hotplug events into containers (as per the presentation > at plumbers) > > > it make more sense to use LXC_PATH/<container>/dev, mount a tiny > > tmpfs on that and then use it? This would have the advantage of having > > I guess one question is whether we think one more mount per container > can become a scalability issue. > > Second question is whether systemd is happier if it sees that /dev is > on devtmpfs.
I've been using regular tmpfs for a while now with systemd and it's fine with it. I don't believe it treats devtmpfs any differently than tmpfs. > > > the same path for privileged and unprivileged containers and avoid the > > ugly lxcpath hash. > > > > > > I believe the following setup would make a bit more sense and offer a > > consistent behaviour: > > - If not available or not a tmpfs, create LXC_PATH/<container>/dev and > > mount a tiny tmpfs on it. Chown the path to the container's root uid/gid > > and chmod to something sane. > > - For all the nodes we care about, attempt to mknod them in there, on > > failure, fallback to touch+bind-mount from real /dev. > > The improved consistency is appealing. > > > This would allow for the exact same code to be used for all 4 cases, for > > the layout and location of the autodev tree to be entirely guessable > > without requiring fancy hashing (making it easier for external tools to > > interact with the autodev tree). > > > > As with the current implementation, the tree wouldn't be flushed on > > container reboot but it would on container shutdown. > > > > > > Does the above make sense or am I missing something about the design of > > current autodev? > > > > Cheers > > > > -- > > Stéphane Graber > > Ubuntu developer > > http://www.ubuntu.com > > > > > _______________________________________________ > > lxc-devel mailing list > > [email protected] > > http://lists.linuxcontainers.org/listinfo/lxc-devel > > _______________________________________________ > lxc-devel mailing list > [email protected] > http://lists.linuxcontainers.org/listinfo/lxc-devel -- Stéphane Graber Ubuntu developer http://www.ubuntu.com
signature.asc
Description: Digital signature
_______________________________________________ lxc-devel mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-devel
