Andrew Clayton
Andrew Clayton
On Wed, 23 Oct 2024 12:28:14 -0700 Gabor Javorszky ***@***.***> wrote: Looks like you deleted this comment... but it's worth replying to... > @javorszky commented on this pull request. >...
> A different question: what do you hope to get out of the answers? Is this question a blocker, or merely a curiosity question? Excuse me? I'm interested in how...
Shouldn't this change from `58cd2578b ("otel: add build tooling to include otel code")` ```diff diff --git ./src/otel/src/lib.rs ./src/otel/src/lib.rs index 34933804..eb1a7bad 100644 --- ./src/otel/src/lib.rs +++ ./src/otel/src/lib.rs @@ -21,7 +21,7 @@ const...
As discussed earlier. [Here](https://github.com/ac000/unit/tree/otel/fixup/otel-patches) are a couple of patches to address coding-style. The readme... ``` These are mostly for coding-style. otel_add_build_tooling_to_include_otel_code.patch Should be applied to ("otel: add build tooling to...
Here's another set of [patches](https://github.com/ac000/unit/tree/otel/fixup/otel-patches) (ignore the ones already applied). I'll just quote the (relevant part of the) commit message here ``` otel: Provide some OTEL fixup patches v02-otel_add_build_tooling_to_include_otel_code.patch Comprises...
> @ac000 question about the patches broken out by files: > ## otel-patches/otel_add_build_tooling_to_include_otel_code.patch This patch is already applied. > 1. In here: https://github.com/ac000/unit/blob/otel/fixup/otel-patches/otel_add_build_tooling_to_include_otel_code.patch#L14, what's the reasoning for having 4 spaces...
> @ac000 I want to take the log callback patches as they perfectly solve the issue of getting the initial logs back into the NGINX Unit logging functions.... but I...
Looks like I forgot to actually push up this [patch](https://raw.githubusercontent.com/ac000/unit/refs/heads/otel/fixup/otel-patches/v01-gitignore_target.patch) which should be applied to 6442694 ("otel: add opentelemetry rust crate code").
> In the final patch you change the log callback signature to accept a 32 bit integer on the rust side..... but from the C side we pass in an...
Actually my main concern was when going from u32 -> u64 Taking x86-64 as an example, even though this wouldn't have this issue. If the rust code is writing 32bits...