On (Mon) Jul 27 2009 [18:44:28], Anthony Liguori wrote: > Jamie Lokier wrote: >> With multiple X servers, there can be more than one currently logged in user. >> >> Same with multiple text consoles - that's more familiar. >> >> Which one owns /dev/vmch3? >> > > For a VMM, copy/paste should work with whatever user has the active X > session that's controlling the physical display. > > Yes, it could get complicated if we supported multiple video cards, but > fortunately we don't :-) > > I really think you need to have a copy/paste daemon that allows multiple > X sessions to connect to it and then that daemon can somehow determine > who is the "active" session. > > This is part of the reason I've been pushing for a concrete example. > All the signs here point to a privileged daemon that delegates to > multiple users. I think just about any use-case will have a similar > model. > > It really suggests that you need _one_ vmchannel that's exposed to > userspace with a single userspace daemon that consumes it. You want the > flexibility of a userspace daemon in determining how you multiplex and > do security. I don't think it's something you want to bake into the > userspace/kernel interface. Right; use virtio just as the transport and all the interesting activity happens in userspaces. That was the basis with which I started. I can imagine dbus doing the copy/paste, lock screen, etc. actions. However for libguestfs, dbus isn't an option and they already have some predefined agents for each port. So libguestfs is an example for a multi-port usecase for virtio-serial. > And if you have a single daemon that serves vmchannel sessions, that > daemon can make it transparent whether the session is going over > /dev/ttyS0, a network device, /dev/hvc1, etc. or /dev/vmch0. it doesn't matter. All minimal virtio devices will look the same. Pop buffers, populate them, push them, etc. Amit -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
