Review at https://gerrit.osmocom.org/4928
ranap_msg_factory: sanitize: memcpy instead of unaligned int copy
The sanitize build complains about writing to a uint32_t that is not 4-byte
aligned. Instead, write the uint32_t by memcpy.
For that, move the common ntohl() to the top and store in a lo
Review at https://gerrit.osmocom.org/4929
cosmetic: ranap_msg_factory: htonl instead of ntohl
In new_transp_layer_addr(), we're composing an outgoing PDU, hence the proper
function to call would be htonl(), not ntohl().
Change-Id: I07979252b7d5a92e8ba11fd088ee06f608fef489
---
M src/ranap_msg_f
Hello Jenkins Builder,
I'd like you to reexamine a change. Please visit
https://gerrit.osmocom.org/4916
to look at the new patch set (#2).
tests: sanitize: clean after tests
Add test_common_cleanup() in test_common.c, call in
test-{helpers,hnbap,ranap}.c, so that any memleaks a sanitize b
Patch Set 1:
Can't judge it (uint32_t could already be in network byte order). Where is the
IP coming from and can that info be put into the commit message?
In the kernel there are defines like __be (out of the top of my head) to
indicate this. Maybe we can do typedef uint32_t no_uint32_t?
--
Patch Set 1: Code-Review+1
(1 comment)
https://gerrit.osmocom.org/#/c/4928/1/src/ranap_msg_factory.c
File src/ranap_msg_factory.c:
Line 651: len = 4;
sizeof(ip_h)?
--
To view, visit https://gerrit.osmocom.org/4928
To unsubscribe, visit https://gerrit.osmocom.org/settings
Gerri
Patch Set 2: Code-Review-1
Due the hierarchical nature of talloc we would silence all msgb's leaks? So the
common code should print the leak count?
--
To view, visit https://gerrit.osmocom.org/4916
To unsubscribe, visit https://gerrit.osmocom.org/settings
Gerrit-MessageType: comment
Gerrit-Ch
Patch Set 2:
(1 comment)
https://gerrit.osmocom.org/#/c/4878/2/src/stream.c
File src/stream.c:
Line 437: talloc_free(msg);
msgb_free.. or we deprecate it.. (if you look at glib when they introduced the
slice allocator/pooling they faced various issues...)..
and we have such "flu
Patch Set 1: Code-Review+1
It does look like the easiest way. So the general rule of thumb is that after
an event dispatch the object could be invalidated? Separate construction from
event transition?
--
To view, visit https://gerrit.osmocom.org/4923
To unsubscribe, visit https://gerrit.osmoc
Patch Set 1: Code-Review+1
--
To view, visit https://gerrit.osmocom.org/4926
To unsubscribe, visit https://gerrit.osmocom.org/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I56551ecc10f5295fe75944bdde4b583b1b621811
Gerrit-PatchSet: 1
Gerrit-Project: osmo-msc
Gerrit-Branch: master
Gerrit
Patch Set 1: Code-Review+1
--
To view, visit https://gerrit.osmocom.org/4922
To unsubscribe, visit https://gerrit.osmocom.org/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: Ib1db8e3dc6c833174f1b0b1ca051b0861f477408
Gerrit-PatchSet: 1
Gerrit-Project: osmo-msc
Gerrit-Branch: master
Gerrit
Patch Set 1: Code-Review-1
so so. As a "policy" we didn't really want to rely on talloc hierarchy (or it's
destructor support). So here we "free" the endpoint.. but what about the socket
fd?
--
To view, visit https://gerrit.osmocom.org/4919
To unsubscribe, visit https://gerrit.osmocom.org/set
Patch Set 1: Code-Review+2
--
To view, visit https://gerrit.osmocom.org/4920
To unsubscribe, visit https://gerrit.osmocom.org/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I53373023a6c3f490d6d6cb1c283db5dfb915882c
Gerrit-PatchSet: 1
Gerrit-Project: osmo-mgw
Gerrit-Branch: master
Gerrit
Patch Set 1: Code-Review+2
--
To view, visit https://gerrit.osmocom.org/4918
To unsubscribe, visit https://gerrit.osmocom.org/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I6823653d5efcebaed40471123d21a9321cf633fd
Gerrit-PatchSet: 1
Gerrit-Project: osmo-mgw
Gerrit-Branch: master
Gerrit
Patch Set 1: Code-Review+2
--
To view, visit https://gerrit.osmocom.org/4917
To unsubscribe, visit https://gerrit.osmocom.org/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I84e0ac7f0928f04ffddd7da18200466841589c25
Gerrit-PatchSet: 1
Gerrit-Project: osmo-mgw
Gerrit-Branch: master
Gerrit
Holger Freyther has abandoned this change.
Change subject: WIP: First invocation of a primitive and callback into lua..
..
Abandoned
--
To view, visit https://gerrit.osmocom.org/4772
To unsubscribe, visit https://gerrit.osmoco
Hello Harald Welte, Jenkins Builder,
I'd like you to reexamine a change. Please visit
https://gerrit.osmocom.org/4737
to look at the new patch set (#4).
mobile: Add initial support for scripting support
Right now the script will be executed once it is loaded. Make sure
to write it into th
Review at https://gerrit.osmocom.org/4930
mobile: Change started and shutdown state through function
Instead of changing the field all over the place, do the state
change in a function. This will allow us to emit a notification
when things change. It is similar to the lchan_state.
Change-Id: I
Hello Harald Welte, Jenkins Builder,
I'd like you to reexamine a change. Please visit
https://gerrit.osmocom.org/4736
to look at the new patch set (#4).
mobile: Add LUA as debug category to the applications
Change-Id: Id2d266c48d30c06dfdc3b8c84d875038b43f2ad8
---
M src/host/layer23/includ
Hello Harald Welte, Jenkins Builder,
I'd like you to reexamine a change. Please visit
https://gerrit.osmocom.org/4771
to look at the new patch set (#3).
mobile: Begin with a primitive interface on top of the code
We want the script interface to interface through a primitive
interface. Thi
Hello Jenkins Builder,
I'd like you to reexamine a change. Please visit
https://gerrit.osmocom.org/4911
to look at the new patch set (#2).
mobile: Avoid msg_ref going out of sync
It seemed like msg_ref could go out of sync. In some places we are
using sms->msg_ref in other cases we pass i
Review at https://gerrit.osmocom.org/4931
mobile: Directly inform the primitive layer about an event
Forward started/shutdown changes to the primitive layer which will
turn them into indications. The other option might be to use the
signals but it seems primitives are a superset of the signals.
Review at https://gerrit.osmocom.org/4932
mobile: Inform the primitive layer about status and new sms
Inform the layer about new SMS and inform about the cause of
it. In both cases pass the SMS.
Change-Id: Ib7ab34b1b85b62ef0e8fff347adccbc5dc414161
---
M src/host/layer23/include/osmocom/bb/mobi
Visit
https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/libasn1c/Debian_9.0/armv7l
Package network:osmocom:nightly/libasn1c failed to build in Debian_9.0/armv7l
Check out the package for editing:
osc checkout network:osmocom:nightly libasn1c
Last lines of build log:
[
Visit
https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/libosmo-abis/Debian_9.0/armv7l
Package network:osmocom:nightly/libosmo-abis failed to build in
Debian_9.0/armv7l
Check out the package for editing:
osc checkout network:osmocom:nightly libosmo-abis
Last lines of
Visit
https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/osmo-ggsn/Debian_9.0/armv7l
Package network:osmocom:nightly/osmo-ggsn failed to build in Debian_9.0/armv7l
Check out the package for editing:
osc checkout network:osmocom:nightly osmo-ggsn
Last lines of build log:
Visit
https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/osmo-msc/Debian_9.0/armv7l
Package network:osmocom:nightly/osmo-msc failed to build in Debian_9.0/armv7l
Check out the package for editing:
osc checkout network:osmocom:nightly osmo-msc
Last lines of build log:
[
Visit
https://build.opensuse.org/package/live_build_log/network:osmocom:latest/libosmo-abis/Debian_9.0/armv7l
Package network:osmocom:latest/libosmo-abis failed to build in Debian_9.0/armv7l
Check out the package for editing:
osc checkout network:osmocom:latest libosmo-abis
Last lines of buil
Visit
https://build.opensuse.org/package/live_build_log/network:osmocom:latest/libsmpp34/Debian_9.0/armv7l
Package network:osmocom:latest/libsmpp34 failed to build in Debian_9.0/armv7l
Check out the package for editing:
osc checkout network:osmocom:latest libsmpp34
Last lines of build log:
[
Visit
https://build.opensuse.org/package/live_build_log/network:osmocom:latest/osmo-trx/Debian_9.0/armv7l
Package network:osmocom:latest/osmo-trx failed to build in Debian_9.0/armv7l
Check out the package for editing:
osc checkout network:osmocom:latest osmo-trx
Last lines of build log:
[ 3
29 matches
Mail list logo
