On 29 November 2016 at 13: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).
>
Can we reuse an established scheme like the one for linux libs ?
>
> 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
> >
> >
>
--
Mike Holmes
Program Manager - Linaro Networking Group
Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs
"Work should be fun and collaborative, the rest follows"
