I think it obfuscates things, adds overhead to maintainence and to app development.
It has to be maintained but it is not strictly necessary, as now, it is already out of date and no one noticed Implementers accidently use it rather than the internal file - overhead to police this. Applications no longer advertise the features they use in their include list, I like that summary at the top of a file, it clearly says that this file deals with crypto for example. When hunting for information I have to go from my app.c to odp.h to find the name of the real include file wanted to look in. I don't like the conceptual coupling, for me coupling is bad when it is not needed for execution - as in this case. The only upside is that apps writers don't wear out their keyboards On 4 September 2014 12:11, Taras Kondratiuk <[email protected]> wrote: > 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. > -- *Mike Holmes* Linaro Technical Manager / Lead LNG - ODP
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
