Attention is currently required from: fixeria.
3 comments:
Commit Message:
Patch Set #2, Line 10: chicken-and-egg problem
It's weird that we ended up having this problem. The usual approach would be: […]
It's as weird as everything else due to this layer23 app concept which adds another layer of indirection and which I'm really hating after having spent so much time in it 😄
The point of having an MS already existing when parsing cmdline opts is the same as for the VTY: it allows setting stuff on the object directly.
The main problem here is that there's a init() function, which I'd like to get called *before* any other call to the layer23app API, so that the app has time to initialize in runtime whatever it wishes. That also includes l23_app_info() which is used during cmd line parsing.
If you move cmdline parsing before l23_app_init(), you call l23_app_info() before l23_app_init() which looks wrong to me. But you still need to allocate the MS in some apps at l23_app_init() time because the MS object needs to be available during VTY config parsing.
So as I was saying, chicken-and-egg problem.
In here, we either:
In any case imho those command lines should be deprecated at some point, and VTY commands be used instead for all apps now that we support VTY in the layer23 common code.
I think you seem to prefer option [A], while I prefer option [B].
File src/host/layer23/src/common/main.c:
Patch Set #2, Line 160: llist_for_each_entry
At the moment only one MS can be using the L1 PHY (accessed via the layer2_socket_path), so it makes […]
It's up to the app to allocate as many structs as it wants. This is not starting the layer2.
Patch Set #2, Line 165: llist_for_each_entry
Same here. A single SAP socket cannot be used by several MS simultaneously. […]
Same as above.
To view, visit change 31354. To unsubscribe, or for help writing mail filters, visit settings.