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...
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,
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 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 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
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 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 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@jabber.hellercom.de
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,
Hi Harald,
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.
Excellent, thanks.
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.
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.
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
-
Bjoern Heller -
Harald Welte -
Holger Freyther -
Lars Immisch