From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Hansen Subject: Re: [RFC][PATCH] Devices visibility container Date: Thu, 27 Sep 2007 08:46:45 -0700 Message-ID: <1190908005.20264.10.camel@localhost> References: <46F77523.9020001@openvz.org> <46F8BD33.5040108@openvz.org> <1190820972.26982.359.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: "Eric W. Biederman" Cc: Linux Containers , Paul Menage , Pavel Emelyanov List-Id: containers.vger.kernel.org On Wed, 2007-09-26 at 13:09 -0600, Eric W. Biederman wrote: > Dave Hansen writes: > > > On Tue, 2007-09-25 at 07:30 -0600, Eric W. Biederman wrote: > >> Pavel Emelyanov writes: > >> > > >> > Oh! Can you provide us an example when after the migration some > >> > device's major+minor pair change on the same device? > >> > >> SCSI disks on a SAN. Network accessible block devices. > >> All kinds of logical/virtual devices like ttys, the loop device, and > >> ramdisks. > >> > >> It isn't especially frequent that something cares, but fundamentally > >> the same issues apply. > > > > To be clear, this just covers cases where an application has > > _internalized_ the device number, right? > > Also cases where you want to call mknod in the container. mknod of device files only, yeah. > > Most applications should be pretty happy with the devices having > > persistent device names across a restart, and we can do that with udev > > and no kernel patching. > > Yes. But the applications that do internalize stat data from files > aren't that uncommon. git, and backup software etc. > > There is also a fair bit of work that is needed to get sysfs > and the hotplug events isolated, when we start allowing mknod etc. > > Basically if I figure if we are going to deal with this we need to handle > the entire problem because these pieces are user visible. I don't > think it is a great priority. Exactly. We have to allow mknod before any of this gets interesting in the least. -- Dave