Re: [MirageOS-devel] Passing tap devices to the main module

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 2 Dec 2014, at 13:22, Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx> 
wrote:
> 
> On 6 Oct 2014, at 11:51, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> 
>> On 6 Oct 2014, at 11:43, Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx> 
>> wrote:
>>> On 5 Oct 2014, at 22:37, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>>> 
>>>> Block devices have another Xenstore numbering scheme that seems far more 
>>>> Linux-specific (and afaict, one that only Dave and Mort understand :-)
>>> 
>>> pshaw. it's in the code. plain for all to see. somewhere.
>>> (just don't ask me to remember it... :)
>>> 
>>> in a spirit of functorisation, it seems like one should be able to pass in 
>>> a function that would generate the next device id as part of the 
>>> configuration of a unikernel, rather than embedding it in some backend 
>>> library (or even frontend tool). or perhaps that's what providing a device 
>>> tree would do?
>> 
>> Yes, but what does 'next' mean here?  What happens if you have three devices 
>> simultaneously hotplugged?  They are mostly independent devices with the 
>> only connection being the unique identifier that Xenstore gives then (via 
>> the backend toolchain), so it seems odd that one device would be required to 
>> give the next one (which is potentially running in a completely separate 
>> domain) it's identifier.
> 
> hm-- yes. 
> 
> tbh i think i had several misunderstandings, notably that i was assuming that 
> it was the guest's job to register an id for the device in xenstore (under a 
> domain prefix) when the device gets hot plugged into the guest, rather than 
> xenstore's job to give each device an id that's unique inside the guest.

Technically, it's not really xenstore's job either.  When a device is 
hotplugged, the toolstack is only responsible for coordinating the 
establishment of a shared memory channel via xenstore.

Typically the backend domain that has the physical device driver runs some 
hotplug script (e.g. udev on Linux), which results in the toolchain 
establishing the backend device (in /local/domain/0, although it can also be in 
another non-0 domain).

This backend device (which has a grant reference to a memory ring, usually) 
then gets passed into the guest VM's xenstore area (/local/domain/<vmid>/) with 
a unique frontend device id that is selected by the toolchain (xend, libxl, 
xapi, etc).

Xenstore is just acting as a distributed database in the middle of this device 
dance of toolchains and domains with different privilege levels...

-anil
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel