On 29 November 2016 at 20:00, Francois Ozog <francois.o...@linaro.org>
wrote:
>
>
> On 29 November 2016 at 19:03, Christophe Milard <
> christophe.mil...@linaro.org> wrote:
>
>>
>>
>> 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).
>>
> [FF]: my thinking was:
> struct devio_t {
> int api_version;
> int devio_version;
> char devio_name[x]} devio[N];
> then you had also
> struct driver_t {
> int api_version;
> int driver_version;
> char drivername_name[x]} drivers[N];
>
> So the matching uses only api_version. object version (devio, driver...)
> is used to change the object (the driver for instance).
> I don't think we want to deal with API compatibility at all. Either the
> API is exactly the same or it is not.
>
[CH]. works for me. I will give a look at Mike's comment, though... :-)
>
>> 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
>>>
>>>
>>
>
>
> --
> [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
>
>
