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.
>
> 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
