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.
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.
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.
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.
- Add low level system message distibution framework
- Add support for local Secure Streams to participate using _lws_smd streamtype
- Add apit test and minimal example
- Add SS proxy support for _lws_smd
See minimal-secure-streams-smd README.md
Now there's an abstract button class regardless of the underlying
connection, we can add more sophicsticated analysis on top of it
for processing its usually noisy events and classifying them into
smd-ready click, long-click or double-click events.
A "regime" defines the timing limits for different press recognition
and can be specified per-button, if not given a default regime is
applied.
String helpers for scanning non-NUL-delimited strings safely,
and very cheap simple string match based JSON parse for cases
that make sense for it... for more complex cases, do a full
JSON parse.
Sometimes we need to find out the substituted length before we can
allocate and actually store it. Teach strexp that if we set the
output buffer to NULL (and the output length to something big) we
are asking for the substituted length and to not produce output.
The low level apis for HMAC (including those only introduced at 1.1.0...)
are all deprecated in OpenSSL v3.
Let's bite the bullet and migrate to EVP, it's already existing in modern
OpenSSL and we already use it for genhash.
EVP needs a PKEY, sort that out and keep it around until the hmac is
destroyed.
Make a start on generic peripheral and bus drivers to provide
meta-functionality regardless of platform.
On the one hand this simply provides...
- bitbang i2c on top of esp-idf gpio apis
- ssd1306 oled chip driver as found on Heltec WB32
- modifications to the minimal example test for esp32 to use that
... on the other hand, those capabilities are provided by creating:
- an abstract i2c class object
- an abstract gpio class object
- i2c class implementation using the abstract gpio for bitbang
- an abstract display class object
- an abstract display state (brightness, animated change,
on/off/init tracking, autodim after inactive, auto-off /
blanking after inactive)
... with the intention, eg, you only have to add a platform
implementation for the gpio to be able to use the i2c-based
display drivers and state handling, and i2c bitbang, without
any other modifications.
LWS_EXTERN needs to be empty for windows when declaring functions in the
headers. But for data, it needs the explicit extern otherwise on windows
or mingw based builds, it thinks we are redeclaring the data each time.
It's not safe to destroy objects inside a callback from a parent that
still has references to the object.
Formalize what the user code can indicate by its return code from the
callback functions and provide the implementations at the parents.
- LWSSSSRET_OK: no action, OK
- LWSSSSRET_DISCONNECT_ME: disconnect the underlying connection
- LWSSSSRET_DESTROY_ME: destroy the ss object
- LWSSSSRET_TX_DONT_SEND: for tx, give up the tx opportunity since nothing to send
lws_dll2 has been available for a couple of years and lws_dll1 marked as
deprecated since v3.2. Remove it.
If it affects you, lws_dll2 has an almost identical api but has more
features, such as storing in the lws_dll2_t which owner it is listed by
and keeping a count of objects on the list at the owner object.
Adapt the pt sul owner list to be an array, and define two different lists,
one that acts like before and is the default for existing users, and another
that has the ability to cooperate with systemwide suspend to restrict the
interval spent suspended so that it will wake in time for the earliest
thing on this wake-suspend sul list.
Clean the api a bit and add lws_sul_cancel() that only needs the sul as the
argument.
Add a flag for client creation info to indicate that this client connection
is important enough that, eg, validity checking it to detect silently dead
connections should go on the wake-suspend sul list. That flag is exposed in
secure streams policy so it can be added to a streamtype with
"swake_validity": true
Deprecate out the old vhost timer stuff that predates sul. Add a flag
LWS_WITH_DEPRECATED_THINGS in cmake so users can get it back temporarily
before it will be removed in a v4.2.
Adapt all remaining in-tree users of it to use explicit suls.
Establish a new distributed CMake architecture with CMake code related to
a source directory moving to be in the subdir in its own CMakeLists.txt.
In particular, there's now one in ./lib which calls through to ones
further down the directory tree like ./lib/plat/xxx, ./lib/roles/xxx etc.
This cuts the main CMakelists.txt from 98KB -> 33KB, about a 66% reduction,
and it's much easier to maintain sub-CMakeLists.txt that are in the same
directory as the sources they manage, and conceal all the details that that
level.
Child CMakelists.txt become responsible for:
- include_directories() definition (this is not supported by CMake
directly, it passes it back up via PARENT_SCOPE vars in helper
macros)
- Addition child CMakeLists.txt inclusion, for example toplevel ->
role -> role subdir
- Source file addition to the build
- Dependent library path resolution... this is now a private thing
in the child CMakeLists.txt, it just passes back any adaptations
to include_directories() and the LIB_LIST without filling the
parent namespace with the details
Esp-idf has an improved but still kind of abused cmake-
based build system now.
If we see ESP_PLATFORM coming as a cmake var, we can know we
are being built from inside the esp-idf config system.
Leave the existing esp32 arrangements alone but triggered off
ESP_PLATFORM, adapt to use the cross toolchain file and
various quirks automatically.
In this way you can build lws a part of your project in a
much cleaner way.
Prepare a minimal esp32 test app for use in Sai
Adapt .sai.json to build for esp32
Add a member to the vh init struct allowing control of the overall
connection wait introduced in an earlier patch. Set it to 20s
by default.
The timeout_secs member controls the individual DNS result
connect timeout and is reduced to 5s by default.
Until now if the generic transaction completes and the connection is idle,
there's a fixed 5s grace period to keep the connection up in case something
else wants it.
This allows setting it in the client creation info struct .keep_warm_secs.
If left at 0, then it maintains the backward-compatible 5s wait.
Add support for blob type in sqlite3... it's unusual in that it
is created into the table schema as a column of blob type, but is
not serialized or deserialized into or from JSON or sqlite.
Because the size of blobs is open-ended, accessing them in one
hit may not be possible, eg, exceed the size of available heap.
As binary, they would have to be base64-encoded in JSON
representation and that bloating may be excessive, with, eg,
a 500MB blob. So while they can be defined using lws_struct
schema, and coexist inside a column of a table managed by
lws_struct, they must be read and written separately.
Lws now strips out http headers releated to h2, ws and unusual headers
based on cmake config settings for those features... it saves some heap
for the ah and reduces the table size in .rodata.
It's possible code might have some external dependency on the original
header indexes, but, eg, you don't enable h2 so those indexes are
optimized with the h2 ones taken out.
This introduces a cmake option "LWS_HTTP_HEADERS_ALL", default-OFF, that
defeats the header table optimization for compatibility with older
versions in the case the client software can't be adapted to use the
lws-exported matching header enums.
You probably don't need this.
By default this doesn't change any existing logging behaviour at all.
But it allows you to define cmake options to force or force-disable the
build of individual log levels using new cmake option bitfields
LWS_LOGGING_BITFIELD_SET and LWS_LOGGING_BITFIELD_CLEAR.
Eg, -DLWS_LOGGING_BITFIELD_SET="(LLL_INFO)" can force INFO log level
built even in release mode. -DLWS_LOGGING_BITFIELD_CLEAR="(LLL_NOTICE)"
will likewise remove NOTICE logging from the build regardless of
DEBUG or RELEASE mode.
In some cases devices may be too constrained to handle JSON policies but still
want to use SS apis and methodology.
This introduces an off-by-default cmake option LWS_WITH_SECURE_STREAMS_STATIC_POLICY_ONLY,
if enabled the JSON parsing part is excluded and it's assumed the user code
provides its policy as hardcoded policy structs.
