20 Feb
2012
20 Feb
'12
9:03 p.m.
Hi,
in some usecases, for people knowing what they are doing, it maybe an
advantage to control osmocombb over the network. Since the VTY is already
network capable, it just needs to bind to an alternative network interface
than localhost.
Here is a patch for layer23 (mobile), having an option "-u" (because -v is
the port). Passing "-u 0.0.0.0" would bind to any interface.
If you think it is useful, please commit it in the git.
Cheers
Tim
20 Feb
20 Feb
9:13 p.m.
If you think it is useful, please commit it in the
git.
It is.
Unfortunately, it's changing libosmocore, so that makes it a whole lot
more complex because you can't change the "shared" directory directly,
we need to make the change to libosmocore then import the new
libosmocore into the osmocom-bb git.
And we have to maintain compatibility in libosmocore as much as
possible if we don't want to break everything that calls telnet_init,
so I would recommend introducing a new telnet_init_ex ? that takes the
added parameter and keep telnet_init as compatibility.
Harald / Holger ? Do you see better ways to handle this sort of case ?
Cheers,
Sylvain
9:24 p.m.
Hi Tim,
Tim Ehlers wrote:
Here is a patch for layer23 (mobile), having an option
"-u" (because
-v is the port). Passing "-u 0.0.0.0" would bind to any interface.
I think this is a fun idea, but I have some small comments.
If you think it is useful, please commit it in the
git.
Please consider the comments, and then re-send a patch created
locally by you using git. It's easy:
One-time setup:
git config --global user.name 'Tim Ehlers'
git config --global user.email your(a)email.address
To create a commit:
git diff # to review your changes and decide that you want them
git commit -a # to create a new commit in your local dir with the changes
Please write a descriptive and nicely formatted commit message.
Your commit message will be visible in many places, so it's a good
idea to make it look really good. It's easy. Here's an example:
-->8--
First line a short description of the logical change, absmax 72 chars
Leave the second line blank, and then, if it makes sense for the
commit, (I don't think neccessary for this one) you can continue
writing a more detailed explanation on lines three and forward.
Always keep line lengths limited. Best is to stay near 70, absmax 76.
Finally, you can end the commit message with a signoff, this practise
has agreed-upon legal meaning within the Linux kernel, but isn't yet
used in the same way within osmocom-bb. It's not wrong to do it anyway.
Signed-off-by: Your Name <your(a)email.address>
--8<--
To generate a patch file for the last 1 commit:
git format-patch -1
Or to have git send the patch directly to the mailing list:
git config sendemail.to baseband-devel(a)lists.osmocom.org # one-time setup
git send-email -1
Or to transmit a copy of your local commits to elsewhere:
# register e.g. on github.com
git push
I really like the git send-email feature. It's great when contributing
sporadically, because you don't neccessarily have to remember the
email address once it has been configured in the git repo! :)
All git commands can be run with --help to learn about their further
capabilities.
//Peter
9:27 p.m.
Sylvain Munaut wrote:
Unfortunately, it's changing libosmocore, so that
makes it a whole lot
more complex because you can't change the "shared" directory directly,
we need to make the change to libosmocore then import the new
libosmocore into the osmocom-bb git.
Yes, good point.
And we have to maintain compatibility in libosmocore
as much as
possible if we don't want to break everything that calls telnet_init,
so I would recommend introducing a new telnet_init_ex ? that takes the
added parameter and keep telnet_init as compatibility.
Are there many uses of telnet_init which can not be fixed very quickly?
Harald / Holger ? Do you see better ways to handle
this sort of case ?
For a "locked" API there's no other way.. Either get the API right
the first time, or pass an extensible set of options. The former is
nice and neat, the latter is a little more complicated.
I think adding a new function is fine, but maybe choose a more
descript name than just the _ex suffix? :)
//Peter
21 Feb
21 Feb
4:50 p.m.
Hi all,
On Mon, Feb 20, 2012 at 09:27:18PM +0100, Peter Stuge wrote:
the problem with fre software is that you never know ;)
At least in openbsc/cellmgr-ng/osmo-sgsn/osmo-nitb/osmo-bsc_mgcp, etc.
they all use the existing function. Also, we really want to avoid the
situation where older versions of openbsc suddenly don't work with a
later version of libosmocore.
I agree that non-local-binding should have been implemented a long time
ago. Usinga 'char *' for the ip/hostname is also the right thing to do.
However, please don't introduce ipv4 assumptions unless required, so
using proper getnameinfo would make sense.
It would also be a good time to start using the general socket helper
code of libosmocore (osmo_sock_init/osmo_sock_init_ofd) to remove code
duplication. A patch along those lines would be appreciated.
Regards,
Harald
--
- 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)
And we have to
maintain compatibility in libosmocore as much as
possible if we don't want to break everything that calls telnet_init,
so I would recommend introducing a new telnet_init_ex ? that takes the
added parameter and keep telnet_init as compatibility.
Are there many uses of telnet_init which can not be fixed very quickly?
4473
days inactive
4473
days old
baseband-devel@lists.osmocom.org
4 comments
4 participants
participants (4)
-
Harald Welte -
Peter Stuge -
Sylvain Munaut -
Tim Ehlers