This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi Sylvain,
On Sat, Jul 24, 2010 at 10:53:07PM +0200, Sylvain Munaut wrote:
> Here's a few refactoring proposal that I'd like to get done. But
> before I invest too much time in them I'd like to be sure there are no
> objections ... (I hate implementing stuff for nothing).
>
> * Split layer23/src into
> - common: what makes liblayer23, purely generic stuff that needs
> binding together to define an app
> - mobile: The real complete mobile application
> - misc: The test applications and their support code layer23 (which
> I'd rename bcch_dump since that's what it does), echo_test, bcch_scan)
Sounds fine with me. If Andreas doesn't mind, I'm happy to merge a branch
containing this split
> * Move away from dispatching L1CTL message using signals ...
>
> Only L1CTL works like that and I just can't figure out why ... we
> read the l1ctl messages just to move their data into another structure
> to redispatch them to a handler ...
>
> l1ctl.c should just contain:
> - The l1ctl_tx_XXX primitives
> - A function for the 'application' to register it's own handler for
> L1CTL messages.
> - The rx call back to be called by lower layer when a l1ctl frame
> is received.
> This one would get the frame, set the hdr pointers, do basic
> checks, possibly allow signal dipatching for the RESET signal (which
> is kinda special), and then just hand the frame to the registered
> handler.
ACK from me, too.
> * Split lapdm.c : Currently it contains lapdm code and RSLms. They
> should be split and lapdm code should not be tied to a specific usage
> but be 'instantiated'/configured in each app as they see fit. Some app
> might need to track more than 2 lapdm channels ...
> - lapdm.c would be in common/ (more like an utility lapdm library
> than 'business' code)
> - rslms.c would probably be in mobile/
I don't have a strong feeling about this, but if you want to do that work, feel
free :)
> * Rework the app in misc/ to remove the over-engineered bits. It's
> clear from the sources that layer23 intended to become the full
> featured phone and as such, is split in a bunch of elements for ...
> not much in the end since Jolly restarted from scratch, splitting
> better. So I'd like to simplify as much as possible those apps while
> still separating 'utilities' function (like dump_bcch) to allow re-use
> between them.
This also sounds very reasonable from my point of view.
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)