On 01/08/2012 02:33 PM, Holger Hans Peter Freyther wrote:
welcome! From my point of view the barrier is not lack
of packages or
documentation but more the lack of affordable hardware.
What do you mean affordable hardware? I guess it's not about servers
running OpenBSC but BTS hardware which is hard to find.
My idea is that if you want cheap hardware go and ask an operator which
is replacing the old BTS equipments with new one from other vendors.
In Germany I know at least 2 operators which are swapping right now with
other vendor all network so you will have on the market thousands of BTS
equipments, mostly Siemens. The problem is power and space because you
will not find micro-cells. They mostly have big ones.
Thank to Jan we have
packages.osmocom.org with
Debian/Ubuntu packages,
our
libraries are also on the way into debian repositories (again thanks
to Jan's
effort). We do not have nightly builds though, I don't know Debian's
policy of
automatically signing nightly builds though.
I already checked the link but the package repository doesn't keep up
with updates from git repository. Most of them were built in the summer
last year, that's why I wanted a nightly built to have the latest bug
fixes and features.
>
> * Did somebody try to build OpenBSC on SPARC architecture? I have
>some Sun
> servers that I would like to use for this project. Same thing like
>before,
> some pre-compiled packages would be nice for SPARC.
Not tham I am aware of.
That's bad because I wanted to run OpenBSC on SPARC and my programming
skills are almost zero and some help with compiling was nice. :=)
I have started generating XML (to be used by docbook or
converted to
Trac Wiki
Syntax) from our VTY (Virtual TeleType) interface. The XML generated
from the
application can be merged (via XSLT) with additional documentation and
then be
included in any kind of documentation.
Normally I prefer the VTY on any kind of hardware configuration but the
VTY for OpenBSC is not so intuitive and helpful that's why I asked for a
web interface to help setup the BSC, BTS and transmission parts.
I guess you were referring to osmo-nitb.
http://openbsc.osmocom.org/trac/wiki/osmo-nitb_VTY
My idea was to change the way it is now and split the commands in:
"list or show or get" - for checking already set parameters
"display" - for checking live parameters, like transport layer errors,
line up, down, BTS up, down
"set,add" - for adding new configuration parameters
"modify" - for changing a parameter value
This will be the main commands and after you can define the parameters
and also split them in some classes like BTS transport layer
configuration, IP or E1 configuration for BSC, Cell and frequency
parameters, etc.
In this way it will be much easier to know what you will configure.
There is more to discuss on this topic...
I don't understand this part, our config files are
plain text and can >be
copied around nicely. I assume you refer to something else. We also
have the
beginning of a Machine-Interface (gdb terminology) but no conclusion
of how to
combine that with the vty.
I was talking about all config parameters to be in one DB and not in
text files. Also it can be an XML file with all configuration and not
many text files.
From VTY just run let's say "backup live-config" command and you will
have an XML with all configuration that you can move on other hardware.
XML should contain everything like E1 or IP settings, BTS and cell
parameters, etc.
To summarize, you are more than welcome to help us on
the
documentation part,
bring more structure to the wiki, create a docbook for OpenBSC,
include the
VTY commands and config options in a reference kind of manual.
I will gladly help but I will need first to make some time. I am very
busy with jobs and kids but I will try in the next weeks to set up a lab
at home for OpenBSC and after we can discuss more based on real facts.
Thank you,
R.