Tighten up the logging at info and have a build summary and version info
at notice level like this
[2020/07/19 07:01:07:5563] N: LWS: 4.0.99-v4.0.0-232-gd602af468, loglevel 1031
[2020/07/19 07:01:07:5567] N: NET IPv6-absent H1 H2 WS MQTT SS-JSON-POL SSPROX ASYNC_DNS
Currently we always reserve a fakewsi per pt so events that don't have a related actual
wsi, like vhost-protocol-init or vhost cert init via protocol callback can make callbacks
that look reasonable to user protocol handler code expecting a valid wsi every time.
This patch splits out stuff that user callbacks often unconditionally expect to be in
a wsi, like context pointer, vhost pointer etc into a substructure, which is composed
into struct lws at the top of it. Internal references (struct lws is opaque, so there
are only internal references) are all updated to go via the substructre, the compiler
should make that a NOP.
Helpers are added when fakewsi is used and referenced.
If not PLAT_FREERTOS, we continue to provide a full fakewsi in the pt as before,
although the helpers improve consistency by zeroing down the substructure. There is
a huge amount of user code out there over the last 10 years that did not always have
the minimal examples to follow, some of it does some unexpected things.
If it is PLAT_FREERTOS, that is a newer thing in lws and users have the benefit of
being able to follow the minimal examples' approach. For PLAT_FREERTOS we don't
reserve the fakewsi in the pt any more, saving around 800 bytes. The helpers then
create a struct lws_a (the substructure) on the stack, zero it down (but it is only
like 4 pointers) and prepare it with whatever we know like the context.
Then we cast it to a struct lws * and use it in the user protocol handler call.
In this case, the remainder of the struct lws is undefined. However the amount of
old protocol handlers that might touch things outside of the substructure in
PLAT_FREERTOS is very limited compared to legacy lws user code and the saving is
significant on constrained devices.
User handlers should not be touching everything in a wsi every time anyway, there
are several cases where there is no valid wsi to do the call with. Dereference of
things outside the substructure should only happen when the callback reason shows
there is a valid wsi bound to the activity (as in all the minimal examples).
For some patterns of JSON we return to parse at the outermost level and
meet a situation path_match is 0. In some places we're looking at things
from perspective of path_match - 1... that does not seem to cause trouble on
x86_64 but can on aarch64, which is how it got noticed.
This logically protects those accesses by checking !!path_match.
The old esp32 -factory stuff along with the lws support doesn't have a
future in its old form. It has users but the ratio of effort to
contribution is really especially bad. I haven't updated it for more
than a year since esp-idf changes broke the original stuff.
Freertos plat is alive and well and getting a lot of new use, ESP-32 is
supported both there and by modern lws_drivers pieces, including in CI
on real hardware, any further effort will be invested in that direction
instead of more vendor api-specific code (outside of wrapper
implementation).
lws_drivers wraps any SDK apis in generic lws apis such that your code
just uses those, enabling it to become SDK / SoC / vendor independent.
Its first implementation is on esp-idf, the low and mid-level features
that were in the old -factory are already available using that and
new technologies like lws_struct and Secure Streams.
As far as I know there are no users of this, although it worked
it's basically unmaintainable due to handling the sql and JSON
manually.
Gradually better capabilities have appeared in lws, like
lws_struct abstracting out the sql and JSON, and now generic
JWT... these have been used in Sai to great effect and displaced
the only organic would-be user of this.
There is a better path to do this stuff now and no point keeping
this around.
There's a good pattern that's encouraged by using lws_struct pieces, that
we have an lws_dll2 owner with an array of objects listed in it that exist
in an lwsac. And because it came from JSON, there is tending to be a
logical name for the objects.
This adds a typed helper and wrapper to scan the owner list looking for
a specific name (of a specified length, not NUL terminated) in a specific
member of the listed objects, which must be a NUL-terminated const char *.
Again this is a good pattern that's encouraged by use of lws_tokenize
to recover the name we're looking for.
So it leads to the helper that can cleanly search for a listed object of the
right name from an owner, and return the typed object pointer or NULL, from a
length-specified string.
Mbedtls mbedtls_x509_crt_parse() returns 0 for success which is good.
But it has a complicated idea about what to return on fail... if it
couldn't make even one cert from the data, then it returns a negative
return indicating the parsing problem and there is nothing to free.
If it managed to parse at least one cert, instead it retuns a positive
number indicating the number of certs it didn't parse successfully,
and there is something to free.
Adapt the code to understand this quirk.
Callbacks can ask the caller to, eg, destroy the ss handle now. But some
callback returns are handled and produced inside other helper apis, eg
lws_ss_backoff() may have to had fulfilled the callback request to destroy
the ss... therefore it has to signal to its caller, and its callers have
to check and exit their flow accordingly.
FreeRTOS only supports nonmonotonic time, when we correct it by, eg,
ntpclient, we offset all the existing sul timeouts. This adds an
internal helper function to correct existing sul timeouts by the
step amount, and call it in lws ntpclient implementation when
adjusting the gettimeofday() time.
This gives a valgrind result for lws-minimal-http-server-event-lib-foreign
that's clean for lws pieces, although glib is always dirty wrt thread local
storage and hashtable.
Add lws_display and minimal example support for esp32-wrover to match wsp32-heltec-wb32
Since no usable buttons that don't affect something else on wrover kit, assumes
a button to 0V on GPIO14.
