[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5386758C.4040702@zytor.com>
Date: Wed, 28 May 2014 16:47:24 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Seth Forshee <seth.forshee@...onical.com>,
linux-kernel@...r.kernel.org, lxc-devel@...ts.linuxcontainers.org
CC: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
James Bottomley <James.Bottomley@...senPartnership.com>,
Serge Hallyn <serge.hallyn@...ntu.com>,
"Michael H. Warfield" <mhw@...tsend.com>,
Marian Marinov <mm@...com>,
Eric Biederman <ebiederm@...ssion.com>,
Richard Weinberger <richard.weinberger@...il.com>,
Andy Lutomirski <luto@...capital.net>,
Michael J Coss <michael.coss@...atel-lucent.com>
Subject: Re: [RFC PATCH 0/2] Loop device psuedo filesystem
On 05/27/2014 02:58 PM, Seth Forshee wrote:
>
> The patches implement a psuedo filesystem for loop devices, which will
> allow use of loop devices in containters using standard utilities. Under
> normal use a loopfs mount will initially contain a single device node
> for loop-control which can be used to request and release loop devices.
> Any devices allocated via this node will automatically appear in that
> loopfs mount (and in devtmpfs) but not in any other loopfs mounts.
> CAP_SYS_ADMIN in the userns of the process which performed the mount is
> allowed to perform privileged loop ioctls on these devices.
>
> Alternately loopfs can be mounted with the hostmount option, intended
> for mounting /dev/loop in the host. This is the default mount for any
> devices not created via loop-control in a loopfs mount (e.g. devices
> created during driver init, devices created via /dev/loop-control, etc).
> This is only available to system-wide CAP_SYS_ADMIN.
>
May I instead strongly advocate a slightly different solution: leave
legacy loop devices where they are, with the current semantics, and let
them be. Make the loopfs loop devices completely independent. Consider
this equivalent of Unix98 ptys versus legacy BSD ptys.
Then, hopefully, use of the legacy ones will disappear over time.
Enabling the new ones in losetup and friends is simple enough; this is
not like ptys where the old scheme was hard-coded into a hundred
different applications.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists