On 4 September 2014 11:54, Victor Kamensky <[email protected]> wrote:
> On 4 September 2014 08:11, Mike Holmes <[email protected]> wrote: > > > > > > > > On 4 September 2014 11:01, Stuart Haslam <[email protected]> wrote: > >> > >> On Thu, Sep 04, 2014 at 03:41:17PM +0100, Victor Kamensky wrote: > >> > On 4 September 2014 03:10, Stuart Haslam <[email protected]> > wrote: > >> > > On Wed, Sep 03, 2014 at 03:18:11AM +0100, Mike Holmes wrote: > >> > >> Signed-off-by: Mike Holmes <[email protected]> > >> > >> --- > >> > >> > >> > >> This creates a new section in the documentaion to group everything > >> > >> related to buffers. It appears to make things much more acessable > >> > >> although it needs to have some real description added to the > section. > >> > >> > >> > > > >> > > Looks better to me. It also allows more freedom within the > >> > > implementation > >> > > to place things in different header files and still have the > >> > > documentation > >> > > look the same. > >> > > >> > If implementations will have freedom to place things in different > >> > headers, > >> > how one app source will work with all of them? Which header it would > >> > include? I am not against fancy doxygen syntax, but mapping ODP > >> > symbol to header file name should be normative part of ODP. Of course, > >> > such mapping could be supported with set of implementation defined > >> > headers that are internally included by one that constitute ODP API. > >> > > >> > Thanks, > >> > Victor > >> > > >> > >> This has come up before and I think the intention has always been that > >> the application should just include odp.h and the implementation can do > >> whatever it likes with header files beyond that (except perhaps that > >> they need to be named odp_*.h). > >> > >> Personally though, I would rather the file names were fixed, and I did > >> wonder when writing that comment whether this decision should be > >> revisited. > >> > > I think in practice this will all work out nicely, but we need to work > with > > it a little, so we can work out the kinks. > > Not sure which way you argue :). Wrt of Stuart's only one odp.h few > remarks: > > o in linux-generic odp_crypto.h and odp_rwlock.h are not included by > odp.h. I guess it is not only me who did not know about one odp.h file > rule. > I think it should be fixed (i.e odp_crypto.h and odp_rwlock.h) must be > added to odp.h. > > Agree, I had to do this in my global_init fix, but it should just be done. Personally I don't believe in odp.h, I think you should include only what you need. > o Examples usage look consistent: most of examples include only odp.h > and helper header files. Only place I found is examples/generator includes > odp_packet_io.h in addition to odp.h (but it should not, because odp.h > does include odp_packet_io.h already) > Agree > > o ODP API Design Guidelines > > https://www.google.com/url?q=https%3A%2F%2Fdocs.google.com%2Fa%2Flinaro.org%2Fdocument%2Fd%2F15ltgSZolCeN66Xmx9rBSAzpxujia0wj4iPrqb2yzlb8%2Fedit > needs section that describes one odp.h header convention, if it is > not there yet (I could not find). > Agree > > Thanks, > Victor > > >> > >> -- > >> Stuart. > >> > > > > > > > > -- > > Mike Holmes > > Linaro Technical Manager / Lead > > LNG - ODP > -- *Mike Holmes* Linaro Technical Manager / Lead LNG - ODP
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
