On 29 November 2016 at 18:13, Francois Ozog <francois.o...@linaro.org>
wrote:
>
>
> On 29 November 2016 at 16:44, Christophe Milard <
> christophe.mil...@linaro.org> wrote:
>
>>
>>
>> On 29 November 2016 at 13:22, Francois Ozog <francois.o...@linaro.org>
>> wrote:
>>
>>> Hi,
>>>
>>> comments inline
>>>
>>> On 29 November 2016 at 10:58, Christophe Milard <
>>> christophe.mil...@linaro.org> wrote:
>>>
>>>> Hi,
>>>>
>>>> In our last meeting, yesterday, we agreed on the following objects:
>>>> 1) enumerator class
>>>> 2) enumerator
>>>> 3) enumerated_device
>>>> 4) devio
>>>>
>>> [FF] we have defined two types of devio: devio-nommu, devio-iommu. The
>>> devio-nommu can be implemented using uio or vfio-nommu interfaces.
>>> devio-nommu abstracts calls to both and ensure it is OS independent.
>>> devio-iommu implement full vfio interface with dma and irq remappings. if
>>> we consider uio as being deprecated, we may just focus on vfio based
>>> devio-nommu and devio-iommu on the first pass and add uio next.
>>>
>>
>> [CH] Agreed, I think. devio-nommu, devio-iommu are two instances of a
>> more general devio object, right?
>>
> [FF] In essence yes but the list of functions on devio-nommu and
> devio-iommu are not the same. So we'll have to deal with casts and have a
> shared list of functions.
>
[CH]: different devio could provide completely different set of ops. I
don't see any problem with that. I am not even sure we should try to
"merge/cast" devios providing the same functionality. what for? this would
just add an extra degree of complexity (dependency between diffferent devio
version), and these function would have to be accesses through different
devio ops anyway
>
>>
>>> 5) driver
>>>>
>>>> and to come: pktio_interface...
>>>>
>>>> At registration time, the driver have to tell:
>>>> - The enumerator class it expects devices from (string E)
>>>> - The devio it intend to use (string D)
>>>>
>>>> [FF]:
>>> 1) the administrator has bound uio or vfio to the device. In that case,
>>> the driver have to be compatible with them.
>>>
>>
>> [CH]: so the driver deals directely with the pci-vfio or pci-uio
>> kernel-driver interface? So some devio module will be kernel drivers, and
>> some other will be ODP modules?
>> My understanding was that the driver would ask for, say, devio-mmu,
>> always.
>> pci-vfio can be used to implement devio-mmu (and probably will), but the
>> driver does not care. it just requires and uses devio-mmu. whether the
>> devio-mmu implementation finds (an already bound) or binds the pcivfio
>> kernel driver is transparent to the ODP device driver. So in my eyes the
>> driver does not have to be compatible with pci-vfio (or uio). the driver is
>> just compatible with devio-mmu. (which is probably a close to a 1:1 mapping
>> to pci-vfio)
>>
>> [FF] devio-nommu abstracts both uio and vfio-nommu as they have the same
> functional spectrum. So the driver does not deal with uio or vfio directly.
> If the device is bound to uio, the device enumerator will pass a
> devio-nommu object whose ops point to uio implementation.
>
[CH] yes.
>
>
>> 2) the administrator did nothing, then it is the driver duty to ask for a
>>> devio-nommu or devio-iommu interface to the enumerator.
>>>
>>
>> [CH] that should happen in any case, I think.
>>
> [FF] this is scenario is mor complex than the other one and may require
> scripting to properly configure vfio. I think we should implement 1) first
> then 2.
>
[CH] OK. I can imagine a devio-nommu trying to bind a kernel driver:
Nothing seems to prevent doing this, so I am fine. we can ignore this case
for now.
>
>>
>>> 3) so I would say that String D is for supported list of devio
>>> interfaces and versions.
>>>
>>
>> [CH] I am not sure why a driver would support many devios, but why not.
>> OK for the versions
>>
> [FF] because we are not in a perfect world. very soon there will be full
> vfio capabilities in x86 and we'll have to have support for that at least
> for virtio-net. And we are not going to have that on ARM for probably a
> year. So the vitio-net driver will have to support both devio-nommu and
> devio-iommu
>
[CH] Ok. I thought this situation could simply be handled with different
drivers. But your approach does not prevent to have different drivers
either, so why not...
so D becomes:
struct {
int major
int minor
char devio_name[x]} devio[N]
i.e. an array of N devio that the driver REQUIRES (rather than supports).
[the driver requires any of the devio in the list, of course. not all.]
Then I guess the driver should be told about the specific devio it is given
to work with (one in the list) at probe time, right? e.g the index in the
range [0...N-1]. The selected devio should have a matching name, same major
and minor(devio) >= minor(driver).
>
>>
>>> Also, the version of these matters! are we OK with a major/minor
>>>> approach?, i.e. the driver will be probed (after registration), only
>>>> for objects enumerated by a compatible enumerator E and if a
>>>> compatible devio D has been registered:
>>>>
>>>> By compatible we mean:
>>>> At registration time enumerators and devios provide a major/minor
>>>> version number
>>>> At registration time, driver provides the requested enumerator and
>>>> devio name and version.
>>>> The register version (of a enumerator or devio) is compatible with the
>>>> requested version if:
>>>> major(requested) = major(registered)
>>>> minor(requested) <= minor(registered)
>>>>
>>>> Does this make sense for you? any better idea?
>>>>
>>>> [FF] If we look at operational cases, I think we cannot allow too much
>>> flexibility. we should define a "device framework" API version and only
>>> allow loaded modules (enumerator classes, drivers...) that have the same
>>> API versions. Then a version can be used to identify bug fixes in the
>>> implementation. This may allow to update a faulty driver live on a system.
>>>
>>
>> [CH] so the major/minor approach should be good enough?
>>
> [FF] yes except the major version does not represent the major version of
> the driver , the enumerator,... it represents the API version to which the
> object complies to. The version increments with bug fixes only on the
> "minor" version which represent the actual version of the driver,
> enumerator...
>
[CH] I guess we agree here: this number reflects API changes: the version
number of a devio would change as follow:
-major number increases when the API changes, breaking previous api
-minor version increases when the API grows, leaving older api elements
unchanged (still usable).
Christophe
>
>>
>>>
>>> Christophe
>>>>
>>>
>>>
>>>
>>> --
>>> [image: Linaro] <http://www.linaro.org/>
>>> François-Frédéric Ozog | *Director Linaro Networking Group*
>>> T: +33.67221.6485
>>> francois.o...@linaro.org | Skype: ffozog
>>>
>>>
>>
>
>
> --
> [image: Linaro] <http://www.linaro.org/>
> François-Frédéric Ozog | *Director Linaro Networking Group*
> T: +33.67221.6485
> francois.o...@linaro.org | Skype: ffozog
>
>
