19 May
2009
19 May
'09
8:44 a.m.
Hey Harald, Andreas,
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.
So the questions I think of are: what are we going to export? how are we going
to export it?
On the what question it mostly depends on Andreas and what he needs for his
application, from what I understand that is the MNCC stuff that will come as
one of his patches.
For the other question of how we are going to export it we have at least two
approaches, symbol filter and visibility attributes of the gcc. I prefer the
later and have cooked up an example patch...
comments welcome
z.
PS: I'm sorry to use libtool... the GNU documentation tries to hide other ways
PPS: With the 2nd patch in place I don't think we need to rename the timer
symbols (we still can as a matter of cleaning it up)
PPS: With the 2nd patch we have everything in place for installable API...
19 May
19 May
9:09 p.m.
On 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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
10:28 p.m.
New subject: BS11 in Berlin? Re: Musings on public API
Hello,
I just wanted to ask whether there is a BS11 that I could have a look
at/play with in Berlin? Does the Club have one or the c-base?
Whom could I kindly ask for a short introduction?
I have experience with Telekom standards/E1/ISDN.
I might be off base here, and I haven't looked at the code beyond
getting it to compile on OS X, but:
Telekom applications always need timers and interfaces to other systems,
and a reactor-style event loop with timers is nearly always the way to
go. You've already got a select loop and timers - why not package it in
a separate lib?
Or offer integration with libevent?
(http://www.monkey.org/~provos/libevent/)
- Lars
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. 
20 May
20 May
1:22 a.m.
New subject: BS11 in Berlin? Re: Musings on public API
Yes, as far as I know there ist a private BS11 from Harald located at
CCCB (correct me if I am wrong).
Also there are some BS11 located at the BHT University Berlin (TFH).
If you want to see them in action just tell me ;)
I will be also from 21. at SIGINT in Cologne, so if you have time to
meet me there...
Best regards
Björn
Am 19.05.2009 um 22:28 schrieb Lars Immisch:
Hello,
I just wanted to ask whether there is a BS11 that I could have a
look at/play with in Berlin? Does the Club have one or the c-base?
Whom could I kindly ask for a short introduction?
I have experience with Telekom standards/E1/ISDN.
I might be off base here, and I haven't looked at the code beyond
getting it to compile on OS X, but:
Telekom applications always need timers and interfaces to other
systems, and a reactor-style event loop with timers is nearly always
the way to go. You've already got a select loop and timers - why not
package it in a separate lib?
Or offer integration with libevent? (http://www.monkey.org/~provos/libevent/
)
- Lars
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Björn Heller
Jabber: tec(a)jabber.hellercom.de
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.
3:21 a.m.
New subject: BS11 in Berlin? Re: Musings on public API
On Tue, May 19, 2009 at 10:28:46PM +0200, Lars Immisch wrote:
I just wanted to ask whether there is a BS11 that I
could have a look
at/play with in Berlin? Does the Club have one or the c-base?
The CCC Berlin has one, it is located underneath the lab table in the basement.
Whom could I kindly ask for a short introduction?
nibbler is probably the only one who is currently in Berlin and who has
played with it. Both zecke and myself are in Taiwan at the moment.
I have experience with Telekom standards/E1/ISDN.
I know :)
Telekom applications always need timers and interfaces
to other systems,
and a reactor-style event loop with timers is nearly always the way to
go. You've already got a select loop and timers - why not package it in
a separate lib?
well, I think we'll just see how OpenBSC is going to be used in order to
see whether the timer interface is needed or not.
Or offer integration with libevent?
(http://www.monkey.org/~provos/libevent/)
might be an option, but I'm personally not particularly happy about adding
external dependencies unless there's a strong need.
btw: Do you have any patches for fixing compilation on OS X ?
Cheers,
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
10:44 a.m.
New subject: BS11 in Berlin? Re: Musings on public API
Hi Harald,
Excellent, thanks.
I noticed (and I approve of that). Your call.
I'd like a pluggable reactor integration (on general considerations).
I'll think about a patch.
I just wanted
to ask whether there is a BS11 that I could have a look
at/play with in Berlin? Does the Club have one or the c-base?
The CCC Berlin has one, it is located underneath the lab table in the basement.
Whom could I kindly ask for a short introduction?
nibbler is probably the only one who is currently in Berlin and who has
played with it. Both zecke and myself are in Taiwan at the moment. I have
experience with Telekom standards/E1/ISDN.
I know :)
Telekom applications always need timers and
interfaces to other systems,
and a reactor-style event loop with timers is nearly always the way to
go. You've already got a select loop and timers - why not package it in
a separate lib?
well, I think we'll just see how OpenBSC is going to be used in order to
see whether the timer interface is needed or not.
Or offer integration with libevent?
(http://www.monkey.org/~provos/libevent/)
might be an option, but I'm personally not particularly happy about adding
external dependencies unless there's a strong need. btw: Do you have any patches for fixing compilation on
OS X ?
Short answer: not yet.
The longer answer is: openbsc compiles with very few modifications on OS
X (congratulations). The only problems are header file annoyances: OS X
has no <malloc.h>, just <malloc/malloc.h>.
Maybe #include <malloc.h> could/should be globally replaced with
#include <stdlib.h>. I'll think about it and suggest a patch.
- Lars
5461
days inactive
5462
days old
5 comments
4 participants
participants (4)
-
Bjoern Heller -
Harald Welte -
Holger Freyther -
Lars Immisch