On 09/04/2014 07:05 PM, Mike Holmes wrote:
On 4 September 2014 11:54, Victor Kamensky <[email protected] <mailto:[email protected]>> wrote: On 4 September 2014 08:11, Mike Holmes <[email protected] <mailto:[email protected]>> wrote: > > > > On 4 September 2014 11:01, Stuart Haslam <[email protected] <mailto:[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] <mailto:[email protected]>> wrote: >> > > On Wed, Sep 03, 2014 at 03:18:11AM +0100, Mike Holmes wrote: >> > >> Signed-off-by: Mike Holmes <[email protected] <mailto:[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.
Mike, which disadvantages common odp.h has? Was there some mail thread there pros and cons of common odp.h were discussed. _______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
