Attention is currently required from: arehbein, daniel, pespin.

fixeria has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bsc/+/34526?usp=email )

Change subject: meas_feed: Use osmo_io instead of write queue ......................................................................

Patch Set 5: Code-Review-1

(2 comments)

File src/osmo-bsc/meas_feed.c:

https://gerrit.osmocom.org/c/osmo-bsc/+/34526/comment/c0b96c80_692b4958 PS5, Line 148: &(struct osmo_io_ops) { : .read_cb = meas_feed_noop_cb, : .write_cb = meas_feed_noop_cb, : .segmentation_cb = NULL, : }, NULL); Can we have this struct defined outside of the function call? IMO, passing a struct pointer like this is not so readable.

https://gerrit.osmocom.org/c/osmo-bsc/+/34526/comment/b998a2e0_83fb04f5 PS5, Line 156: meas_feed_txqueue_max_length_set(MEAS_FEED_TXQUEUE_MAX_LEN_DEFAULT This looks suspicious. I see a few potential problems:

* Scenario a): in the config file `meas-feed write-queue-max-length <1-65535>` goes before `meas-feed destination ADDR <0-65535>`: in this case you're overwriting the user's setting with `MEAS_FEED_TXQUEUE_MAX_LEN_DEFAULT`. * Scenario b): a user willing to change the destination addr/port entering the VTY and issuing the `meas-feed destination ADDR <0-65535>` command: in this case you're again overwriting the user's setting with `MEAS_FEED_TXQUEUE_MAX_LEN_DEFAULT`.

I think the correct way would be to call:

``` osmo_iofd_set_txqueue_max_length(g_mfs.io_fd, g_mfs.max_length); ```