Hi Enrico, Thanks for your feedback! The "container friendliness" design point is intentional, and can certainly be used to give each user/session their own /dev instance.
I haven't added it yet, but it will be possible to signal a vdev instance to reload its configuration (i.e. send it SIGUSR1 or similar). Is that what you're getting at? If not, can you flesh out your example a bit more? Thanks, Jude On Tue, Dec 23, 2014 at 11:45 AM, Enrico Weigelt, metux IT consult < [email protected]> wrote: > > On 17.12.2014 22:10, Jude Nelson wrote: > > > * If you're worried about testing and debugging vdev, you'll be pleased > > to know that it can run concurrently with udev, on any mountpoint you > > want. You can even run multiple instances of vdev independently. > > *THAT* is a really cool feature. It would also allow unusual setups > like having a separate instance managing eg. a container or chroot > (_outside_ that one). > > > There is a HUGE advantage to using FUSE that I think outweighs the > > quirks: you get per-process access control for free, since FUSE tells > > you which task ID issued the request (which vdev uses to query the > > calling process and filter device nodes accordingly). This is much > > simpler than systemd-logind's approach, which has to authenticate the > > calling process itself, open the device file descriptor, and send it to > > the calling process via dbus (thereby requiring the calling process to > > speak dbus and link against systemd-logind's dbus interface). > > At that point, we could give each user/session an own /dev instance, > so the processes only see their own device tree (possibly only those > device nodes which are accessible to the user). > > By the way: is there already some communication channel to reconfigure > an running instance from the outside ? (eg. if stuff should change on > console changes, etc) If not, maybe we could add somthing 9P based. > > > cu > -- > Enrico Weigelt, > metux IT consulting > +49-151-27565287 > _______________________________________________ > Dng mailing list > [email protected] > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng >
_______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
