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.
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
