additional API related to device management and not "packetio" related:
https://lwn.net/Articles/677967/ FF On 29 November 2016 at 20:35, Christophe Milard < christophe.mil...@linaro.org> wrote: > > > 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 >> >> > -- [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
