This has the advantage that any caller or other reference does not
need to know the size of the set, which makes it simpler to use the
sched_set as a constant initializer in some other const/static data
structure.
The write queue can be a dropin replacement for the bsc_fd. It
is featuring two callbacks. One for ready read and one for ready
write. Whenever there is a message in the queue the write_queue
will set the BSC_FD_WRITE flag and then call the write callback.
It will make sure to delete the msgb after the write function
has been called. This class is intended to be be used in the
osmocom, layer2, bsc_msc_ip, bsc_hack and other applications.
In commit 9a18ba40d940c9bf173504b941e10f9638032823 (old git), this
was changed to 'fix compiler warnings'.
But %ux is not a valid format specifier at all so that produces
wrong output !
%lx is the correct format AFAICT because uint32_t is typedef'd from
unsigned long in my toolchain (ARM GCC 4.3.3 - newlib 1.17.0). This
doesn't produce any warning here.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Using #define TPU_DEBUG, we can now send the full TPU RAM contents
to the host PC (using a sercomm DLCI) at the time of tpu_enable()
which is very helpful for TPU debugging.
If we perform the downlink calibration too early, the TRF6151 might
not yet provide a stable signal and we'll not be able to receive
anything.
From the desired "BDLENA" time, we subtract all the delays and
latencies to determine the point in time at which the calibration
process should start.
In the sercomm_cons layer, ee used to enqueue a msgb for sending
every time there is an end-of-line. However, if we send a number
of very short lines, we easily run out of msgbs.
Now we check how much msgb backlog there is in the transmit queue,
and decide to skip the end-of-line flushing if needed.
This still doesn't solve all our problems, but its still a useful
mechanism.
libosmocore is a new library that has been created out of OpenBSC,
and it provides almost everything we've tried here with libosmocom.
The only remaining part is the 'debug' part
* remove commented-out code
* explain what GSMTAP is and reference projects that can generate it
* update copyright notice
I will submit this to wireshark mainline now.
The cause is really not clear. The formual using 2*Pi to convert
from radians to frequency is perfectly correct.
However, measurements with various test equipment (including Racal 6103)
have shown our frequency error estimate is always off by a power of two...
Harald Welte
Holger Hans Peter Freyther
Sylvain Munaut