[ofw] complib and cl_nodenamemap

[Sean Hefty]

Sasha,

I'd like to see about doing 'something' with nodenamemap.  Currently, it's part
of complib, but the interfaces and operation are not similar to other complib
type abstractions.

>From what I can tell, nodenamemap performs two abstractions.  At a lower level,
it implements functionality similar to cl_map.  The main difference is that
cl_map requires the user to allocate space for the object being inserted into
the map.  If we add a new call to complib, we can provide an abstraction of the
functionality that nodenamemap requires:

cl_map_insert_copy(cl_map_t *p_map, uint64_t key,
			void *p_object, size_t object_size);

There would be internal changes needed to free the object, plus changes to
cl_map_remove return values for copied objects.

At a higher level, nodenamemap parses an application specific file and stores
the contents of the file into a map.  I'm not sure that this functionality
really belongs as a part of complib.  But regardless, it makes more sense to me
to separate the parsing of the file from maintaining the data in a map.

There's not a need to abstract opening or closing the file.  So the only
functionality that's needed is parsing a line of input from the file.  Each
application could link in the necessary code directly, the parsing code could go
into a new 'ibcommon' library (not really worth it for 1 call), or the file
format just needs to be generic enough to work with a wide variety of
applications (and maybe it already is).

Is it acceptable to change or remove the nodenamemap abstraction from complib,
and if so, is there a specific direction to take?

- Sean