Re: [lng-odp] Driver registration: object version control

[Francois Ozog]

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 
> wrote:
>
>>
>>
>> On 29 November 2016 at 19:03, Christophe Milard <
>> christophe.mil...@linaro.org> wrote:
>>
>>>
>>>
>>> On 29 November 2016 at 18:13, Francois Ozog 
>>> wrote:
>>>


 On 29 November 2016 at 16:44, Christophe Milard <
 christophe.mil...@linaro.org> wrote:

>
>
> On 29 November 2016 at 13:22, Francois Ozog 
> 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 

Re: [lng-odp] Driver registration: object version control

[Christophe Milard]

On 29 November 2016 at 20:00, Francois Ozog 
wrote:

>
>
> On 29 November 2016 at 19:03, Christophe Milard <
> christophe.mil...@linaro.org> wrote:
>
>>
>>
>> On 29 November 2016 at 18:13, Francois Ozog 
>> wrote:
>>
>>>
>>>
>>> On 29 November 2016 at 16:44, Christophe Milard <
>>> christophe.mil...@linaro.org> wrote:
>>>


 On 29 November 2016 at 13:22, Francois Ozog 
 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 

Re: [lng-odp] Driver registration: object version control

[Francois Ozog]

On 29 November 2016 at 19:03, Christophe Milard <
christophe.mil...@linaro.org> wrote:

>
>
> On 29 November 2016 at 18:13, Francois Ozog 
> wrote:
>
>>
>>
>> On 29 November 2016 at 16:44, Christophe Milard <
>> christophe.mil...@linaro.org> wrote:
>>
>>>
>>>
>>> On 29 November 2016 at 13:22, Francois Ozog 
>>> 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 

Re: [lng-odp] Driver registration: object version control

[Mike Holmes]

On 29 November 2016 at 13:03, Christophe Milard <
christophe.mil...@linaro.org> wrote:

> On 29 November 2016 at 18:13, Francois Ozog 
> wrote:
>
> >
> >
> > On 29 November 2016 at 16:44, Christophe Milard <
> > christophe.mil...@linaro.org> wrote:
> >
> >>
> >>
> >> On 29 November 2016 at 13:22, Francois Ozog 
> >> 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 

Re: [lng-odp] Driver registration: object version control

[Christophe Milard]

On 29 November 2016 at 18:13, Francois Ozog 
wrote:

>
>
> On 29 November 2016 at 16:44, Christophe Milard <
> christophe.mil...@linaro.org> wrote:
>
>>
>>
>> On 29 November 2016 at 13:22, Francois Ozog 
>> 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 

Re: [lng-odp] Driver registration: object version control

[Francois Ozog]

On 29 November 2016 at 16:44, Christophe Milard <
christophe.mil...@linaro.org> wrote:

>
>
> On 29 November 2016 at 13:22, Francois Ozog 
> 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.

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


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

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


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

>
>
>>
>> Christophe
>>>
>>
>>
>>
>> --
>> [image: Linaro] 
>> François-Frédéric Ozog | *Director Linaro Networking 

Re: [lng-odp] Driver registration: object version control

[Christophe Milard]

On 29 November 2016 at 13:22, Francois Ozog 
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] 
> François-Frédéric Ozog | *Director Linaro Networking Group*
> T: +33.67221.6485
> francois.o...@linaro.org | Skype: ffozog
>
>

Re: [lng-odp] Driver registration: object version control

[Francois Ozog]

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.

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.
2) the administrator did nothing, then it is the driver duty to ask for a
devio-nommu or devio-iommu interface to the enumerator.
3) so I would say that String D is for supported list of devio interfaces
and 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.

Christophe
>



-- 
[image: Linaro] 
François-Frédéric Ozog | *Director Linaro Networking Group*
T: +33.67221.6485
francois.o...@linaro.org | Skype: ffozog