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(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)