On Sat, Aug 22, 2015 at 01:21:59PM +0000, Serge Hallyn wrote: > Quoting Wolfgang Bumiller ([email protected]): > > We came across lxc's #195 while working on our frontend to support > > mount entries via lxc.mount.entry. > > > > The issue there (despite the change of the title) seems to be just the > > `loop' option (which ends up passed to mount(2) as part of the > > `data'). > > > > There's already code for loop devices, and a loop 'bdev' type for a > > `loop:` prefixed rootfs, so adding support for loop mounts shouldn't > > be all too hard (I'm willing to work on that.) > > > > I'm also wondering, however, if the use of libmount has been considered > > before? Admittedly I haven't looked too deeply into it yet, but it's > > what the mount command uses and so I'd assume it supports all the > > various options. (Though maybe more than desired due to security > > concerns?) Let me know if this has already come up (the big search > > machine hasn't found much ;-P). > > Don't think it's been discussed before. I wouldn't be opposed. We > have a few lxc.mount.entry options like 'create=file' which we'd need > to filter out, but that's ok. I've not looked at the api enough to > know whether it would simplify or complicate our code. The mount > calls themselves are pretty simple. Does libmount automatically handle > things like readonly bind mounts?
So I have my usual concern about availability on Android and other embedded platforms (openwrt and the like) too. If we can make using libmount an opt-in thing (when available), then it'd be fine I guess. I just want to keep the number of hard external dependencies reasonably low. -- 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
