Some refactoring proposals

Harald Welte laforge at gnumonks.org
Tue Jul 27 14:28:25 UTC 2010


Hi 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)




More information about the baseband-devel mailing list