This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgOn Tue, May 19, 2009 at 08:44:01AM +0200, Holger Freyther wrote:
> I just tried to come up with a patch to prefix the timer functions with bsc_
> and started to think about public API. The thing is we only need to properly
> prefix symbols we intend to export. I don't think we will export timers.
well, it basically depens on how you want to see openbsc/libbsc.
If you treat it as a library, then of course exporting timers is a stupid
idea. However, if OpenBSC is an application program / daemon that also
supports plugins, then providing infrastructure such as timers to the
plugins is a good idea.
I wasn't really sure about the way to go so far. I think in reality we might
need both. The sole reason to have libbsc was that there is some code reuse
between bsc_hack and bs11_config, and now even ipaccess_config.
I think all practical cases will not really see libbsc as a public library. I
think the BSC functionality warrants its own daemon, possibly with multiple
processes/threads, one for the signalling and one or more for the TRAU
handling. The question is how to treat interfaces to programs like lcr.
Should we just offer a plugin API and let such users write a plugin that
performs the IPC to the actual external program - or should we provide some
kind of standardized IPC interface and a library that people can link into
their application programs...
My main focus for OpenBSC has been to have a playground for BSC-like
functionality that is as flexible as possible. So my intention is to have a
toolkint of A-bis and other GSM prtoocol related bits (libbsc) plus a set of
programs/plugins that can turn the code into something useful. a PBX is one
of many examples, but a program that fuzzes telephones over the air would
be another of those applications.
p.s.: I don't mind libtool at all.
Regards,
--
- 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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090520/5e51be6e/attachment.bin>