Attention is currently required from: neels, pespin.

Patch set 3:Code-Review +1

View Change

3 comments:

• File include/osmocom/pfcp/pfcp_msg.h:

  • Patch Set #3, Line 69: static inline uint32_t osmo_pfcp_next_seq(uint32_t *seq_state)

    This function will return 1 on first call most probably. […]

    I would expect no constraint whatsoevre on the starting / initial value of the sequence number. Basically every command must have a unique serial number so we can match responses to requests, and the receiver can distinguish re-transmission of a command (same seq) from a new command (different seq)

  • Patch Set #3, Line 72: (*seq_state) &= 0xffffff;

    the interesting question is why we use a uint32_t variable if we only use 16 bits of it?

  • Patch Set #3, Line 110: struct osmo_fsm_inst *peer_fi;

    Looks like these 2 groups can be in a union?

    peers and sessins are orthogonal concepts, why do you think a message is only either part of a session or related to a peer? shouldn't it be both at the same time?

To view, visit change 27631. To unsubscribe, or for help writing mail filters, visit settings.