summaryrefslogtreecommitdiffhomepage
AgeCommit message (Collapse)AuthorFilesLines
2024-03-09Pretty print the PHP language module compiler outputAndrew Clayton1-2/+4
This makes use of the infrastructure introduced in a previous commit, to pretty print the make output when building the PHP language module. You can still get the old verbose output with $ make V=1 ... Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Pretty print the Perl language module compiler outputAndrew Clayton1-3/+5
This makes use of the infrastructure introduced in a previous commit, to pretty print the make output when building the Perl language module. You can still get the old verbose output with $ make V=1 ... Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Pretty print the Java language module compiler outputAndrew Clayton1-3/+5
This makes use of the infrastructure introduced in a previous commit, to pretty print the make output when building the Java language module. You can still get the old verbose output with $ make V=1 ... Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Hook up make pretty printing to the Unit core and testsAndrew Clayton1-20/+40
This makes use of the infrastructure introduced in the previous commit to pretty print the make output when building the Unit core and the C test programs. When building Unit the output now looks like VER build/include/nxt_version.h (NXT_VERSION) VER build/include/nxt_version.h (NXT_VERNUM) CC build/src/nxt_lib.o CC build/src/nxt_gmtime.o ... CC build/src/nxt_cgroup.o AR build/lib/libnxt.a CC build/src/nxt_main.o LD build/sbin/unitd SED build/share/man/man8/unitd.8 I'm sure you'll agree that looks much nicer! You can still get the old verbose output with $ make V=1 ... Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Add initial infrastructure for pretty printing make outputAndrew Clayton1-0/+29
The idea is rather than printing out the full compiler/linker etc command for each recipe e.g cc -c -pipe -fPIC -fvisibility=hidden -O0 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wno-strict-aliasing -Wmissing-prototypes -g -I src -I build/include \ \ \ -o build/src/nxt_cgroup.o \ -MMD -MF build/src/nxt_cgroup.dep -MT build/src/nxt_cgroup.o \ src/nxt_cgroup.c Print a clearer abbreviated message e.g the above becomes CC build/src/nxt_cgroup.o This vastly reduces the noise when compiling and most of the time you don't need to see the full command being executed. This also means that warnings etc show up much more clearly. You can still get the old verbose output by passing V=1 to make e.g $ make V=1 ... NOTE: With recent versions of make(1) you can get this same, verbose, behaviour by using the --debug=print option. This introduces the following message types CC Compiling a source file to an object file. AR Producing a static library, .a archive file. LD Producing a dynamic library, .so DSO, or executable. VER Writing version information. SED Running sed(1). All in all this improves the developer experience. Subsequent commits will make use of this in the core and modules. NOTE: This requires GNU make for which we check. On OpenIndiana/illumos we have to use gmake(1) (GNU make) anyway as the illumos make doesn't work with our Makefile as it is. Also macOS seems to generally install GNU make. We could make it work (probably) on other variants of make, but the complexity starts increasing exponentially. In fact we still print the abbreviated messages in the verbose output so you can still do $ make | grep ^" [A-Z]" on other makes to effectively get the same output. Co-developed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Compile with -fno-strict-overflowAndrew Clayton1-0/+4
This causes signed integer & pointer overflow to have a defined behaviour of wrapping according to two's compliment. I.e INT_MAX will wrap to INT_MIN and vice versa. This is mainly to cover existing cases, not an invitation to add more. Cc: Dan Callahan <d.callahan@f5.com> Suggested-by: Alejandro Colomar <alx@kernel.org> Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Disable strict-aliasing in clang by defaultAndrew Clayton1-2/+4
Aliasing is essentially when you access the same memory via different types. If the compiler knows this doesn't happen it can make some optimisations. There is however code in Unit, for example in the wasm language module and the websocket code that may fall foul of strict-aliasing rules. (For the wasm module I explicitly disable it there) In auto/cc/test for GCC we have NXT_CFLAGS="$NXT_CFLAGS -O" ... # -O2 enables -fstrict-aliasing and -fstrict-overflow. #NXT_CFLAGS="$NXT_CFLAGS -O2" #NXT_CFLAGS="$NXT_CFLAGS -Wno-strict-aliasing" So with GCC by default we effectively compile with -fno-strict-aliasing. For clang we have this NXT_CFLAGS="$NXT_CFLAGS -O" ... #NXT_CFLAGS="$NXT_CFLAGS -O2" ... NXT_CFLAGS="$NXT_CFLAGS -fstrict-aliasing" (In _clang_, -fstrict-aliasing is always enabled by default) So in clang we always build with -fstrict-aliasing. I don't think this is the best idea, building with something as fundamental as this disabled in one compiler and enabled in another. This patch adjusts the Clang side of things to match that of GCC. I.e compile with -fno-strict-aliasing. It also explicitly sets -fno-strict-aliasing for GCC, which is what we were getting anyway but lets be explicit about it. Cc: Dan Callahan <d.callahan@f5.com> Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Expand the comment about -Wstrict-overflow on GCCAndrew Clayton1-1/+3
Expand on the comment on why we don't enable -Wstrict-overflow=5 on GCC. Link: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96658> Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Remove -W from compiler flagsAndrew Clayton1-2/+2
This is what -Wextra used to be called, but any version of GCC or Clang in at least the last decade has -Wextra. Cc: Dan Callahan <d.callahan@f5.com> Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Remove support for Sun's Sun Studio/SunPro C compilerAndrew Clayton4-140/+0
We really only support building Unit with GCC and Clang. Cc: Dan Callahan <d.callahan@f5.com> Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Remove support for IBM's XL C compilerAndrew Clayton3-176/+1
We really only support building Unit with GCC and Clang. Cc: Dan Callahan <d.callahan@f5.com> Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Remove support for Intel's icc compilerAndrew Clayton1-11/+0
We only really support building Unit with GCC and Clang. Cc: Dan Callahan <d.callahan@f5.com> Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Remove support for Microsoft's Visual C++ compilerAndrew Clayton2-13/+0
We don't run on Windows and only really support compiling Unit with GCC and Clang. Cc: Dan Callahan <d.callahan@f5.com> Co-developed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-08Var: Fix cacheable issue for njs variable accessZhidao HONG1-1/+1
The variables accessed with JS template literal should not be cacheable. Since it is parsed by njs engine, Unit can't create indexes on these variables for caching purpose. For example: { "format": "`{bodyLength:\"${vars.body_bytes_sent}\",status:\"${vars.status}\"}\n`" } The variables like the above are not cacheable. Closes: https://github.com/nginx/unit/issues/1169
2024-03-07.mailmap: Map Dylan's 2nd GitHub addressDylan Arbour1-0/+1
I changed a setting and now GitHub will recognize both the legacy numberless version, and the newer version with UserID. The with-UserID version will be used by the any changes stemming from the GitHub GUI. Reviewed-by: Andrew Clayton <a.clayton@nginx.com> Signed-off-by: Dylan Arbour <d.arbour@f5.com>
2024-03-07Add GitHub workflow for wasm-wasi-componentAndrew Clayton1-5/+35
This adds a GitHub CI workflow for the new wasm-wasi-component language module. Some things of note. 1) We need to special case 'wasm-wasi-component' in the 'Output build metadata' section as we are splitting the module names on '-' to split them into name and version. 2) Apart from needing to tell bindgen about the njs include paths, we also need to explicitly specify which version of clang to use to work around an issue with multiple versions of clang installed. Link: <https://gitlab.freedesktop.org/mesa/mesa/-/issues/7268> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-07Test with root access in GitHub workflowsDylan Arbour1-31/+13
To enable tests that require privileged root access, this commit tests with `sudo`. The Java and Python jobs have additional permissions issues, so they are also configured and made with `sudo`. A small permissions fix is required before running tests to allow non-root users to execute within the `/home/runner` directory. This change also removes the custom directories that were required without root access. Reviewed-by: Andrew Clayton <a.clayton@nginx.com> Signed-off-by: Dylan Arbour <d.arbour@f5.com>
2024-03-05Avoid potential NULL pointer dereference in nxt_router_temp_conf()Andrew Clayton1-7/+9
In nxt_router_temp_conf() we have rtcf = nxt_mp_zget(mp, sizeof(nxt_router_conf_t)); if (nxt_slow_path(rtcf == NULL)) { goto fail; } If rtcf is NULL then we do fail: if (rtcf->tstr_state != NULL) { nxt_tstr_state_release(rtcf->tstr_state); } In which case we will dereference the NULL pointer rtcf. This patch re-works the goto labels to make them more specific to their intended purpose and ensures we are freeing things which have been allocated. This was found by the clang static analyser. Reviewed-by: Zhidao Hong <z.hong@f5.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-05Var: Remove a dead assignment in nxt_var_interpreter()Andrew Clayton1-1/+1
p is not used again before returning from the function. Found by the clang static analyser. Reviewed-by: Zhidao Hong <z.hong@f5.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-05Remove unused nxt_vector_t APIAndrew Clayton4-223/+0
This is unused, yet a community member just spent time finding and fixing a bug in it only to be told it's unused. Just get rid of the thing. Link: <https://github.com/nginx/unit/pull/963> Reviewed-by: Zhidao Hong <z.hong@f5.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-02-29Configuration: Fix check in nxt_conf_json_parse_value()Andrew Clayton1-1/+1
If we compile Unit with -Wstrict-overflow=5 (as we do with clang) then we get the following warning cc -c -pipe -fPIC -fvisibility=hidden -O0 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wstrict-overflow=5 -Wmissing-prototypes -g -I src -I build/include \ \ \ -o build/src/nxt_conf.o \ -MMD -MF build/src/nxt_conf.dep -MT build/src/nxt_conf.o \ src/nxt_conf.c src/nxt_conf.c: In function ‘nxt_conf_json_parse_value’: src/nxt_conf.c:1444:5: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C2 -+ C1 [-Wstrict-overflow] 1444 | if (nxt_fast_path((ch - '0') <= 9)) { | Does this actually cause an issue?... well, yes. Using this minimal test config to show the problem { "listeners": { "[::1]:8080": { "pass": --100 } } } With the above if () statement that triggers the warning, my assumption here is that we only want a digit now. '0' - '9'. ch is a u_char, however if ch is any character with an ASCII code < 48 ('0') e.g if ch is '-' (45) then we get 45 - 48 = -3, through arithmetic conversion, which makes the if () statement true (when it shouldn't) then at some point we get the following error returned from the controller { "error": "Memory allocation failed." } Instead of the expected { "error": "Invalid JSON.", "detail": "A valid JSON value is expected here. It must be either a literal (null, true, or false), a number, a string (in double quotes \"\"), an array (with brackets []), or an object (with braces {}).", "location": { "offset": 234, "line": 15, "column": 27 } } Casting the result of (ch - '0') to u_char resolves this issue, this makes the above calculation come out as 253 (relying on unsigned integer wraparound) which was probably the intended way for it to work. Reviewed-by: Zhidao Hong <z.hong@f5.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-02-27Wasm-wc: use more common uname switch to get operating system nameKonstantin Pavlov1-1/+1
-o is not available on macOS 12.7 at least, and it's what homebrew seems to support still. Also, the proposed switch seems to be used already in the codebase.
2024-02-27Version bumpAndrei Zeliankou2-2/+34
2024-02-27Added version 1.32.0 CHANGES1.32.0Andrei Zeliankou3-3/+56
2024-02-27Generated Dockerfiles for Unit 1.32.0Andrei Zeliankou14-28/+28
2024-02-27Edited changes.xml for the 1.32.0 releaseAndrei Zeliankou1-10/+80
2024-02-24Update setup-go to v5Dylan Arbour1-1/+2
Removes deprecation notices on actions builds. v5 updates the version of node and `cache: false` disables the errors related to not finding a go.sum
2024-02-23Add PHP 8.2 and 8.1 to test matrixDylan Arbour1-0/+4
`setup-php` action was fixed to add embed SAPI for older versions of PHP
2024-02-22Packages: Pass CFLAGS to compile wasm modules on all packaging targetsKonstantin Pavlov2-3/+3
This extends the approach used for debian-based packages in 3f805bc64e28 to rpm as well. Notable change for both deb and rpm packaging is to use CFLAGS as defined in the build/Makefile, and not pass them from the environment which might not be there (as is the case for rpm). While at it, stop passing CFLAGS in the install phase, as it should no longer invoke builds (see d54af163c46b). The rpm part was overlooked in 7a6405566c0, since testing was not done on the platforms where problem manifested itself, notably Amazon Linux 2023 and Fedora 38+.
2024-02-22Remove debug from builds and testsDylan Arbour1-2/+1
The info and above errors should be more than enough for debugging failures in GitHuB Actions CI.
2024-02-22Update third-party java components to their recent versionsSergey A. Osokin3-15/+15
Acked-by: Timo Stark <t.stark@nginx.com> [ Remove trailing '.' from subject line - Andrew ] Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-02-22Wasm-wc: Use the cargo build output as the make target dependencyAndrew Clayton1-3/+5
cargo build creates the language module under src/wasm-wasi-component/target/release/libwasm_wasi_component.so and not build/lib/unit/modules/wasm_wasi_component.unit.so which is what we were using as a target dependency in the Makefile which doesn't exist so this resulted in the following $ make wasm-wasi-component-install cargo build --release --manifest-path src/wasm-wasi-component/Cargo.toml Finished release [optimized] target(s) in 0.17s install -d /opt/unit/modules install -p src/wasm-wasi-component/target/release/libwasm_wasi_component.so \ /opt/unit/modules/wasm_wasi_component.unit.so I.e it wanted to rebuild the module, after this patch we get the more correct $ make wasm-wasi-component-install install -d /opt/unit/modules install -p src/wasm-wasi-component/target/release/libwasm_wasi_component.so \ /opt/unit/modules/wasm_wasi_component.unit.so This is all a little ugly because we're fighting against cargo wanting to do its own thing and this wasm-wasi-component language module build process is likely going to get some re-working anyway, so this will do for now. Reported-by: Konstantin Pavlov <thresh@nginx.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-02-22Wasm-wc: Add nxt_unit.o as a dependency in the auto scriptAndrew Clayton1-2/+1
Rather than calling make itself to build nxt_unit.o make nxt_unit.o a dependency of the main module build target. Reported-by: Konstantin Pavlov <thresh@nginx.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-02-21Packages: added wasm-wasi-component module packaging for rpm-based distrosKonstantin Pavlov1-3/+3
2024-02-21Packages: added wasm-wasi-component module packaging for deb-based distrosKonstantin Pavlov1-3/+3
We need to redefine CFLAGS to drop missing-prototypes as warning since third-party code such as wasmtime fails to build from source when building a debian package. This happens only for packages because we use DPKG_EXPORT_BUILDFLAGS=1 propagating build flags to the environment, so cargo build picks it up as well. Since we have no control over third-party code, the easiest solution is to disable this warning.
2024-02-21Tests: renamed test_python_procman.py since it's not Python-specificAndrei Zeliankou1-0/+0
Python applications are used only to generate responses here and can be replaced by applications written in any other language. While the "_python" prefix is used to indicate that the file contains tests specific to the Python module.
2024-02-21Tests: skip some of TLS reconfiguration tests under AddressSanitizerAndrei Zeliankou1-0/+7
These tests cause router crash when run with AddressSanitizer: ================================================================= ==77196==ERROR: AddressSanitizer: heap-use-after-free on address 0x60c000079340 at pc 0x55d56b132d4b bp 0x7f8cc7f346b0 sp 0x7f8cc7f346a0 READ of size 1 at 0x60c000079340 thread T1 #0 0x55d56b132d4a in nxt_openssl_conn_io_shutdown src/nxt_openssl.c:1466 #1 0x55d56b0f6a25 in nxt_h1p_closing src/nxt_h1proto.c:2069 #2 0x55d56b1009a6 in nxt_h1p_shutdown src/nxt_h1proto.c:2038 #3 0x55d56b1014c3 in nxt_h1p_request_close src/nxt_h1proto.c:1718 #4 0x55d56b1045c0 in nxt_http_request_close_handler src/nxt_http_request.c:864 #5 0x55d56b104988 in nxt_http_request_done src/nxt_http_request.c:795 #6 0x55d56b0ba0c3 in nxt_event_engine_start src/nxt_event_engine.c:542 #7 0x55d56b0dcac2 in nxt_router_thread_start src/nxt_router.c:3645 #8 0x55d56b0b421b in nxt_thread_trampoline src/nxt_thread.c:126 #9 0x7f8ccab95ac2 (/lib/x86_64-linux-gnu/libc.so.6+0x94ac2) #10 0x7f8ccac2784f (/lib/x86_64-linux-gnu/libc.so.6+0x12684f)
2024-02-21Tests: check for the AddressSanitizer flag during discoveryAndrei Zeliankou2-0/+3
This flag is necessary to either run or skip certain tests that have specific behavior depending on whether AddressSanitizer is enabled. For instance, some tests may fail only when the binary is compiled with AddressSanitizer.
2024-02-21Tests: Ruby hook tests unstable for version older 3.0Andrei Zeliankou1-1/+4
It can fail with reporting following alert: [alert] 137462#137462 mount("none", "/tmp/unit-test-636e0uh8/proc", "proc", 2097162, "") (16: Device or resource busy)
2024-02-21Docker: Re-generate Dockerfile.wasmAndrew Clayton1-7/+8
This now includes support for the 'wasm-wasi-component' module. This targets the upcoming 1.32.0 release which is required by wasm-wasi-component. However of course the 1.32.0 tag doesn't exist yet, so there will be a small window where this image won't build. Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-02-21Docker: Add wasm-wasi-component to the wasm targetAndrew Clayton1-3/+4
Thus $ make build-wasm will build _both_ the 'wasm' & 'wasm-wasi-component' modules. Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-02-21Docker: Bump rust version to 1.76.0Andrew Clayton1-1/+2
The minimum version required to build wasmtime 17 which is required by wasm-wasi-component is 1.73.0 But no point not using the latest version. This also now needs the libclang-dev package installed, we install this via MODULE_PREBUILD_wasm. Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-02-21Wasm-wc: Wire it up to the build systemAndrew Clayton3-0/+128
Et voila... $ ./configure wasm-wasi-component configuring wasm-wasi-component module Looking for rust compiler ... found. Looking for cargo ... found. + wasm-wasi-component module: wasm_wasi_component.unit.so $ make install test -d /opt/unit/sbin || install -d /opt/unit/sbin install -p build/sbin/unitd /opt/unit/sbin/ test -d /opt/unit/state || install -d /opt/unit/state test -d /opt/unit || install -d /opt/unit test -d /opt/unit || install -d /opt/unit test -d /opt/unit/share/man/man8 || install -d /opt/unit/sh man/man8 install -p -m644 build/share/man/man8/unitd.8 /opt/unit/share/ma n8/ make build/src/nxt_unit.o make[1]: Entering directory '/home/andrew/src/unit' make[1]: 'build/src/nxt_unit.o' is up to date. make[1]: Leaving directory '/home/andrew/src/unit' cargo build --release --manifest-path src/wasm-wasi-component/Cargo.toml Finished release [optimized] target(s) in 0.55s install -d /opt/unit/modules install -p src/wasm-wasi-component/target/release/libwasm_wasi_component.so \ /opt/unit/modules/wasm_wasi_component.unit.so Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-02-21Fix alignment of wasm options text in auto/helpAndrew Clayton1-2/+2
The indentation uses spaces and not TABs. Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-02-21Wasm-wc: Wire up the language module to the config systemAndrew Clayton3-0/+35
This exposes the various WebAssembly Component Model language module specific options. The application type is "wasm-wasi-component". There is a "component" option that is required, this specifies the full path to the WebAssembly component to be run. This component should be in binary format, i.e a .wasm file. There is also currently one optional option "access" Due to the sandboxed nature of WebAssembly, by default Wasm modules/components don't have any access to the underlying filesystem. There is however a capabilities based mechanism[0] for allowing such access. This adds a config option to the 'wasm-wasi-component' application type (same as for 'wasm'); 'access.filesystem' which takes an array of directory paths that are then made available to the wasm module/component. This access works recursively, i.e everything under a specific path is allowed access to. Example config might look like "applications": { "my-wasm-component": { "type": "wasm-wasi-component", "component": "/path/to/component.wasm", "access" { "filesystem": [ "/tmp", "/var/tmp" ] } } } The actual mechanism used allows directories to be mapped differently in the guest. But at the moment we don't support that and just map say /tmp to /tmp. This can be revisited if it's something users clamour for. [0]: <https://github.com/bytecodealliance/wasmtime/blob/main/docs/WASI-capabilities.md> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-02-21Wasm-wc: Add Cargo.lockAndrew Clayton2-2/+2293
It seems we do want to track this thing. This is just the latest version that cargo had generated for me. Cc: Dan Callahan <d.callahan@f5.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-02-21Wasm-wc: Allow to use the 'reactor' adaptor againAndrew Clayton1-1/+2
With the initial port to wasmtime 17 we could no longer use the 'reactor' adaptor but had to switch to the more restrictive 'proxy' adaptor. This meant amongst other things (probably) we could no longer access the filesystem. Thanks to Joel Dice for pointing out the fix. With this we can go back to using the 'reactor' adaptor again and things are back to working as before. It's worth noting that you can use either the 'proxy' or 'reactor' adaptor depending on your requirements. Cc: Joel Dice <joel.dice@fermyon.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-02-21Wasm-wc: Upgrade to wasmtime 17Andrew Clayton2-16/+17
This brings WASI 0.2.0 support. Link: <https://github.com/bytecodealliance/wasmtime/releases/tag/v17.0.0> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-02-21Wasm-wc: Improve request buffer handlingAndrew Clayton1-7/+14
When Unit receives a request, if the body of that request is greater than a certain amount (16KiB by default) then it is written to a temporary file. When a language module goes to read the request body in such situations it will end up using read(2). The wasm-wasi-component language module was failing to properly read request bodies of around 2GiB or more. This is because (on Linux at least) read(2) (and other related system calls) will only read (or write) at most 0x7ffff000 (2,147,479,552) bytes, this is the case for both 32 and 64-bit systems. Regardless, it's probably not a good idea doing IO in such large chunks anyway. This patch changes the wasm-wasi-component language module to read the request buffer in 32MiB chunks (this matches the original 'wasm' language module). We are still limited to a 4GiB address space and can only upload files a little under 4GiB. Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-02-21Wasm-wc: Run src/lib.rs through rustfmtAndrew Clayton1-31/+84
Run from the repository root like $ rustfmt --edition 2021 src/wasm-wasi-component/src/lib.rs Also manually fix up some overly long comments. Signed-off-by: Andrew Clayton <a.clayton@nginx.com>