Janne Karhunen <janne.karhunen@xxxxxxxxx> writes: > On Tue, Mar 19, 2013 at 5:37 PM, Serge Hallyn <serge.hallyn@xxxxxxxxxx> wrote: > >>> > Well the devcg was meant to be a temporary stopgap solution until we >>> > have device namespaces, and this seems to entrench them further, but >>> > it does make sense. >>> >>> Just out of interest, what would such device namespace actually >>> do other than switch the device access on/off according to callers >>> namespace? >> >> It could also support mapping of <type>:maj:min inside namespace to >> a different device on host. In most cases we probably don't actually >> want that, but it's an interesting enough thing to be worth thinking >> through. > > It sounds to me that what you really want to do is likely use case and > device specific. Hence the idea about namespace specific ioctl device > action(s) might not be so bad. It would certainly be less intrusive than > tampering with device registrations or rerouting nod file_operations for > instance. > > Classic on/off toggle case is easy though, but are there enough > reasons for merging such 'noop' namespace? The two most compelling cases are: - Container migration. - Safe creation of virtual devices. Now I think we can solve container migration by effectively hotuplugging and hotplugging all of our devices. The safe creation of virtual devices that I am thinking of are essentially ptys (already covered with devpts) and loopback devices. There are probably a couple more that I don't know off the top of my head. So far I haven't found any case that is sufficiently compelling, and can't be replaced by acting like devtmpfs and controlling all device creation. Although I have heard of cases where applications still call mknod even with devtmpfs and udev doing most of the work. I am of the general thought that we should explore what we can do with what we have now, at least until we find a compelling case for doing more in the kernel. Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
