Hi, On 12/05/12 15:23, Diego Biurrun wrote:
On Sat, May 12, 2012 at 02:53:01PM +0300, Xin Gu wrote:On 12/05/12 14:00, Diego Biurrun wrote:On Sat, May 12, 2012 at 10:13:17AM +0300, Xin Gu wrote:On 11/05/12 00:55, Diego Biurrun wrote:@@ -202,6 +166,47 @@ +lib_hipl_libhipl_la_SOURCES = lib/hipl/accessor.c \ + lib/hipl/lhipl.c \ + lib/hipl/lhipl_sock.c \ + lib/hipl/lhipl_operations.c \Why this lhipl prefix?It is a short form for libhipl. This prefix can help to identify src code files related to libhipl.There is no need to identify files in the libhipl directory as belonging to libhipl. What else would they belong to? We don't have hipfw_ and hipd_ prefixes in the hipd/ and hipfw/ directories.I was not so clear in previous reply. This prefix aims to identify src code files related to library-based HIP.Maybe it was not clear enough in my previous reply: We have a directory to identify source code files related to librarized HIPL, there is no need for a prefix.
Those files with lhipl prefix are the implementation of the library-based HIP (see my merge proposal). The prefix can group them together so everyone can tell them easily. If you think current prefix is not intuitive, I am fine to change it to something you propose.
Regrading to memleak, I didn't find suspicious records from the output of valgrind related to library-based HIP. One improvement I make is closing the libhipl socket when the unit tests finish.
Xin