Quoting Eric W. Biederman ([email protected]): > riya khanna <[email protected]> writes: > > > (Please pardon multiple emails, artifact of merging all separate > > conversations) > > > > Thanks for your feedback! > > > > Letting the kernel know about what devices a container could access (based > > on > > device cgroups) and having devtmpfs in the kernel create device nodes for a > > container that map to corresponding CUSE nodes is what I thought of. For > > example, "echo 29:0 > /proc/<pid>/devices" would prepare a virtual > > framebuffer > > (based on real fb0 SCREENINFO properties) for this process provided > > permissions > > allow this operation. To view the framebuffer, the CUSE based virtual device > > would talk to the actual hardware. Since namespaces would have different > > view of > > the underlying devices, "sysfs" has to made aware of this as well. > > > > Please let me know your inputs. Thanks again! > > The solution hugely depends on what you are trying to do with it. > > The situation today is that device nodes are slowly fading out. In > another 20 years linux may not have any device nodes at all. > > Therefore the question becomes what are you trying to support. > > If it is just filtering of existing device nodes. We can do a pretty > good approximation with bind mounts. > > If you want to emulate a device you can use normal fuse (not cuse). > As normal fuse file will support arbitrary ioctls. > > There are a few cases where it is desirable to emulate what devpts > does for allowing arbitrary users to creating virtual devices in the > kernel. Loop devices in particular. > > Ultimately given the existence of device hotplug I don't see any call > for being able to create device nodes with well known device numbers > (fundamentally what a device namespace would be about). > > The conversation last year was about people wanting to multiplex devices > that don't have multiplexer support in the kernel. If that is your > desire I think it is entirely reasonable to device type by device type > add support for multiplexing that device type to the kernel, or > potentially just use fuse or cuse to implement your multiplexer in > userspace but that has the potential to be unusably slow.
It would be helpful to have a list of devices that may want that multiplexing. Is it really just loop and graphics drivers? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
