view rvinterf/include/limits.h @ 752:c79aaed75bd8

compile-fc-batt: allow possible third field in source lines Battery tables maintained in the fc-battery-conf repository will now have a third field added, defining thresholds for the battery bars icon, and there will be a new utility to compile them into the new /etc/batterytab2 file read by the FC Tourmaline version of our FCHG driver. For backward compatibility with the original Magnetite version of FCHG, compile-fc-batt remains the tool for compiling the original /etc/batterytab file format, and it needs to ignore the newly added third field in battery table sources.
author Mychaela Falconia <falcon@freecalypso.org>
date Thu, 05 Nov 2020 20:37:55 +0000
parents e7502631a0f9
children ca6e969be6ee
line wrap: on
line source

/*
 * For sizing our buffers etc in the rvinterf suite, including the local
 * UNIX domain socket protocol between rvinterf and fc-tmsh etc, we need
 * to have some limits on the message sizes in both host->target and
 * target->host directions.
 *
 * For the host->target direction, the choice of message size limit is
 * easy: the packet Rx code in RVT on the target side also has a limit
 * (quite naturally, as it needs to use a static buffer to reassemble
 * incoming packets as they arrive at the UART in unpredictable interrupt-
 * sized chunks), so we set our limit to match that in RVT.
 */

#define	MAX_PKT_TO_TARGET	255

/*
 * In the other direction (target->host), there is no fixed limit
 * definition easily visible in the target fw code: any fw component
 * can call rvt_send_trace_cpy() or rvt_mem_alloc() followed by
 * rvt_send_trace_no_cpy(), or some higher-level API that reduces to
 * these functions, with a message of any size, subject only to memory
 * limits, which obviously aren't as strict as a #define'd maximum
 * message size.  Hence in this direction we use our own arbitrary
 * choice of size limit.
 */

#define	MAX_PKT_FROM_TARGET	512

/*
 * Both limit definitions above counts all bytes between the opening and
 * closing STX flags, but not DLEs inserted for binary transparency.
 */