[net2-wg] Incremental Radio Interface Update for 2.1.1

[Stephen Dawson-Haggerty]

>
> I think it boils down to a code size vs. RAM size issue. Queueing has a
> larger RAM cost than locking. I'd like to see what the code size costs are.
> I'm not sure what would be more, the locking or the queue management. One
> issue there is that locking scales pretty linearly with clients, while
> virtualization has only a small incremental cost per client. But I'd expect
> we're not talking about tons of clients, so this is less of a concern than
> the constant factors.

I'm also very very concerned about the code size issue, especially in
the common case where there is only one client (network).  In fact,
the patch I sent it includes tests for the case where there is only
one client and uses simplified logic-- this saves about 300 bytes ROM
over the more general case.  The queuing is about as simple as I can
make it, and it uses FcfsResourceQueue to actually do the queuing.

Steve