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 <
enrico.weigelt@???> 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
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>