Anders, Christophe and I had a discussion and here are some very rough
notes on what I think settled out of it.
Requirements:
We wanted something that scales if more interfaces to ODP are defined and
openStack was suggested as the sort of east/west that may occur
We want the actual driver implementations to be externally developed and
use the odp_driver interface, but not be part of the odp reference repo,
they will be in their own repo and are a lot like regular applications in
how they relate to the api.
Applications use drivers and odp platforms as needed, thus at a top level
in the diagram there are three entities, with the application attaching the
drivers it wants.
The tree should make sense in its ordering of includes, with a higher
level including from below generally and not bouncing up and down with ../
etc
We would like different entry points to help debugging, for example in a
log to be able to distinguish a driver dma operation from an application
dma operation even though the implementation will be identical on that
platform.
We would like to be able to alter the interfaces independently for the same
basic concept - maybe dma in once case needs different semantics to the
other, who knows what we may find.
.
├── odp_drivers
│ ├── my_nic1
│ │ └── my_code.c
│ └── my_nic2
│ └── my_code.c
├── my_application
│ └── my_code.c
└── odp
├── include
│ ├── odp
│ │ ├── api
│ │ └── driver
│ ├── odp_driver.h
│ └── odp.h
└── platform
└── linux-generic
└── include
├── api
│ ├── plat
│ └── shared_memory.h
└── driver
└── shared_memory.h
The discussion ended up suggest changing to creating facades, one for each
of the different interfaces to a ODP Platform.
So in odp_driver.h and in odp.h you may have two facades for the same
common code in the platform for say dma access. These two facades can have
a different prefix to the same code :- odp_dma for applications (north
bound) and odpd_dma for drivers (south bound) and they end up reusing the
same .c file and function implementation.
We had open questions:
1. Do we need the odp_driver to have something down under platform to make
this work ?
2. How do we solve the includes - note that in the diagram under
linux-generic/include we renamed odp to api for symmetry in discussion,
that is not how it is currently.
On 11 January 2016 at 12:30, Christophe Milard <christophe.mil...@linaro.org
> wrote:
> Hi,
>
>
>
> Today the situation as I see it, is as follows:
>
> We have a single interface to ODP, the application interface, A.
>
> This interface is defined by a file which any application includes:
> include/odp.h
>
>
> <odp.h> includes in turn a set of
> platform/<platform>/include/odp/<module.h>.
> These files are given a chance to define platform specific types by
>
> including platform/<platform>/include/odp/plat/<module_types>.h, do their
>
> own definitions (such as inlines functions) and finishes by including
>
> /odp/include/odp/api/<module.h>, which will mainly have for effect to
> check
> that the platform definitions do match the generic api definition.
>
>
>
> With the driver interface being defined, we are about to add another
> interface
> D (D as driver).
>
> It seems that some of you would like to have a /odp/include/odp/D
> directory
> which would contains driver specific <module.h>, e.g. dma.h.
>
> While I understand the wish to keep interface separated, I am not conviced
>
> that this really fits the job...:
>
> How does this new directory work?.
>
> an include file, called D.h (at the same level as odp.h, it seems we could
>
> agree here) would include what from the platform?
>
> platform/<platform>/include/D/<module.h>? which in turn would include:
>
> platform/<platform>/include/D/plat/<module_types>.h and finally
> /odp/include/odp/api_D/<module.h>?
> OK. that works. maybe complicated but does work. But more to the point:
> what
> is the criteria for the modules to be in the A (normal appli api) or D
> directory?
> D directories would contain any module just included by the D interface
>
> whereas A directories woud contain modules either part of A and D or A
> only?
> This overlap is where I see the main issue: What if an X interface has to
> be
> created in the future (Petri named open stack as an exemple), and Y and Z?
>
> All partly overlapping... What will be the criteria to place the different
>
> modules (m.h) in the A, D,X, Y or Z directories? I cannot see that growing
> well...
> Also the function prefix would get messy: should a function used in the A
> and D
> and Y interface be called A_f(), D_f(), Y_f() or ADY_f()? and change name
> when Z comes?
>
>
> The other approach (chosen by the patch serie, but actually not fully
>
> implemented there) is different:
>
> platform/<platform>/include/odp/*
>
> platform/<platform>/include/odp/plat/<module_types>.h
>
> and /odp/include/odp/api/<module.h> (which we should rename EPI (instead
> of API)
> maybe, for External Programing Interface) would define all functions
> exported
> by ODP. On ANY interface.
>
> All these functions are prefixed by odp_*. as today. Saddly, one cannot
> tell by
> the name of function only which interface it belongs to.
>
> That actually makes sense as we accept functions to be part of many
> interfaces
> at the same time.
>
>
>
> The file include/odp/<interface_name>.h (e.g. Api.h, driver.h X.h,Y.h or
> Z.h)
> just lists the functions (module .h files, that may have to be splitted if
>
> modules define function for different interfaces) belonging to that
> interface.
>
>
> Overlap is no longer a problem and directory contents becomes clear and
>
> well defined.
>
>
>
> The definition on each interface is done by the interface ".h" file.
>
> not a directory.
>
> Does it matter?
>
> Overlap is clean: the corresponding module symply being listed many times
> in the
> different interface definition files they belong to.
>
> Less directories, and no question on where a module belonging to interface
>
> A,D Z,Y or Z should end-up.
>
> Specific directories and function prefix make only sense to me when the
>
> interfaces do not overlap, or overlapping functions get aliases
>
> (A_f() and D_f() being the same).
>
> Thanks for reading. Hope we'll find the optimal solution together.
>
>
>
> /Christophe.
>
--
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp
