[PATCH] [RFC] src: add prefix osmocom_ to all functions in libosmocore

[Harald Welte]

Hi Pablo,

On Mon, Mar 28, 2011 at 05:27:42PM +0200, Pablo Neira Ayuso wrote:
> Some minor questions:
> 
> On 27/03/11 22:20, Harald Welte wrote:
> > Exceptions:
> > * libosmovty should have a common vty_ prefix, but not osmo.
> > * for libosmovty we should probably simply limit the number of exported
> >   symbols.  There is e.g. all the buffer_*() and vector_*() use internally,
> >   but there is no need to globally export all those symbols.
> > * no osmo_ prefix for msgb_* and tlv_*, as they are used everywhere
> > * no prefix for talloc
> > * bitvec_* -> osmo_bv_*
> 
> enum bit_value -> enum osmo_bit_value
> struct bitvec -> struct osmo_bitvec

both fine with me.  I think Sylvain wanted to be a bit less 'aggressive'
with renaming, but the point is: We're breaking the API anyway, so we
might as well do it properly once and hopefully not have to care about
it in the future.

> there are some inconsistencies in the API naming in the timer bits:
> 
> bsc_add_timer(...)
> bsc_timer_pending(...)
> 
> I can put the timer postfix in the end, so it looks consistent.

I think it should all be called osmo_timer_* for consistency.

> struct timer_list should be struct osmo_timer_list, right?

ACK.

> > * *_signal_* -> osmo_signal_*
> 
> Is there any plan to remove the static lists inside the library?

no, I don't have such plans, and I don't think it is neccessarry. The
signalling system is not intended to have multiple instances.  There is
one in every process, that's it.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)