On Wed, Oct 15, 2008 at 09:02:30AM -0500, Anthony Liguori wrote:
>>> like struct sockaddr_un. As long as the strings were unique, they
>>> could be in whatever format people wanted.
>>>
>>>
>> So basically what you are saying is that you want to use string IDs instead
>> of
>> numerical IDs in a hope that the chance of colliding IDs will be smaller?
>> (in the
>> current implementation ID length is 32 bit, so the chances for two services
>> to
>> pick the same ID is small).
>>
>
> But people don't choose random 32-bit integers and since your
> implementation only supports channels 0..4 obviously, the intention
> isn't to choose random integers. When using integers, it would be
You can configure only four channels in qemu with my implementation, but
you can give arbitrary ID to each one of them. To configure vmchannel
with ID 42 you add "-vmchannel di:42,unix:/tmp/kvm-mouse,server"
to qemu command line ("di" means Device Id).
> necessary to have some sort of authority that assigns out the integers
> to avoid conflict. A protocol like this scales better if such an
> authority isn't necessary.
>
>> But why pick constant ID for a service at all? Management software can
>> assign unique IDs for each service during image preparation.
>
> First, not everyone has "management software". Even so, it's not the
If you run qemu without "management software" as most of us do, you
became "management software". If you want Linux console to be on a
serial port you have to configure qemu and Linux properly.
> center of the world. If I want to add a new feature to QEMU that makes
> use of one of these channels (say Unity/Coherence), does that mean I now
> have to tell every management tool (libvirt et al) about this interface
> so they can assign an ID to it? How does the guest software know what
With proposed solution yes, you have to tell it to a management tool.
Not only because of ID assigning issues, but also because you have no
direct control on a command line, so management tool should know how to
create a channel for you. Of cause management tool can have an option to
add channels on user request.
> channel to use? You basically assume yet another host<=>guest
> communication mechanism to tell the guest software what channel to use.
> That seems to defeat the purpose.
This happens when disk image is prepared and various agents are installed into
it. Just as if you want to redirect Linux console to serial port you
have to add kernel option once after installation.
>
>> So one
>> management software will use channel 42 for DnD and 22 for CIM and another
>> will use 13 for DnD and 42 for CIM. All is need is to not hard code
>> channel IDs into agents. You will not be able to move such images from one
>> management software to another easily of cause, but this task is not so easy
>> today too.
>>
>
> It's so much simpler to just use unique identifiers for each service.
> Be it UUID, a string in the form of a reverse fqdn or URL, or whatever.
>
It is easy to do with "name resolution" service on channel 0.
>> If you like string IDs better
>> than numerical IDs and you are OK with "lookup by name" way of doing
>> things in VMCI I can easily add channel 0 (will be implemented by qemu
>> itself and thus always present) that will do name to ID mapping.
>>
>
> It's not a bad idea to have a bootstrap channel. Do channel exist
> during the entirely life time of the guest?
Yes.
> Can disconnects/reconnects
> happen on a channel? Can a guest listen on a channel?
Netlink implements datagram semantic, so there is not
disconnects/reconnects or listen. Any process can send/receive data
to/from any channel.
>
> Certainly, sockets are a pretty well established model so it makes a
> certain amount of sense to have these things behave like traditional
> sockets.
>
I use socket! Existing one, not new one. I think there should be a very
good reason to add yet another address family. I thought about adding new
address family initially, but then I recalled that we already have one
that is used for kernel<->userspace communication.
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
