[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communic

From: Gerd Hoffmann
Subject: Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
Date: Mon, 10 Aug 2009 17:34:31 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Lightning/1.0pre Thunderbird/3.0b2

On 08/10/09 16:20, Anthony Liguori wrote:
Gerd Hoffmann wrote:
Do we really want design a daemon and a protocol for such a simple thing?

Yes, because we also need (c) the ability to write cross platform
software that targets vmchannel.

So having a library interface is going to be extremely desirable.

You don't need a daemon for that though.

Also, see the previous discussion about security. How do you sanely
delegate /dev/vmchannel/org/qemu/clipboard to the current Xorg user?

pam_console (I think that is the name of the beast).
Or is it handled by hal these days?

The piece of software which does the very same thing already for sound and other devices.

Especially as requiring a daemon for that adds a few problems you
don't have without them. Access control for example: For device nodes
you can just use standard unix permissions and acls.

But how do you set those permissions in the first place?

See above. There are other devices which need that too. There are existing solutions for this problem.

You can easily do stuff like adding the logged in desktop user to the
/dev/vmchannel/org/qemu/clipboard acl using existing solutions. With a
daemon you have to hop through a number of loops to archive the same.

Can't we simply have guest apps open "/dev/vmchannel/$protocol" ?

/dev interfaces are only simple to kernel developers :-) Besides, why do
something that can be clearly done in userspace within the kernel?

Ok, lets rip out the in-kernel ioapic code then. It can (and has been) done in userspace.

just increases the possibility of kernel bugs.

The daemon increases the possibility of userspace bugs.

Seriously: Attaching a name tag to virtio-serial devices and have them exposed via sysfs is probably *much* less code than a vmchannel daemon.

Also multiplexing over one device introduces a number of problems you have to take care of on both sides (qemu+daemon) of the connection. For example: When the communication stalls in one protocol the others should keep on going of course. With one device per protocol and thus one virtqueue per protocol the problem doesn't exist in the first place.

You can have a /var/run/vmchannel/$protocol.sock unix domain socket and
it has all the same properties that you describe. It also Just Works
with standard tools like socat.

bash: socat: command not found

If we really want
vmchannel to be used by application developers, then we really need a

We need a sane solution developed and merged and not a new idea each week.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]