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