Skip to content

Conversation

@alexmohr
Copy link
Contributor

Summary

Add the soruce code, CI, readme etc for the DLT libraries.
Please note that the generated documentation is commited on purpose.
This way it can be viewed in a browser without downloading, building locally or publishing on crates.io.
See

Only caveat right now is that linking between the two crates does not work.

Checklist

  • I have tested my changes locally
  • I have added or updated documentation
  • I have linked related issues or discussions
  • I have added or updated tests

Related

Notes for Reviewers

Alexander Mohr alexander.m.mohr@mercedes-benz.com, Mercedes-Benz Tech Innovation GmbH
Provider Information

@@ -0,0 +1,180 @@
/*
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would rather split it in dlt-rs-sys and dlt-rs with safe rust api. At least this is the best practice

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer dlt-rs and dlt-sys. As the dlt-rs doesn't interact with the sys library anymore but only the rust wrapper.
Would be similar to openssl and in line with what you suggested in slack.

# SPDX-License-Identifier: Apache-2.0

[package]
name = "dlt-tracing-appender"
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would favor <vendor>-tracing-dlt. This follows the naming schema in the tracing repository.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would 'tracing-dlt' be okay for you?
i.e. otel doesn't have a vendor either
https://docs.rs/tracing-opentelemetry/latest/tracing_opentelemetry/

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Totally fine with me. I thought that if we push this to crates.io we might cause conflicts with the tracing- prefix. Feel free to use tracing-dlt

Copy link
Contributor Author

@alexmohr alexmohr Nov 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done, dlt-tracing is still free on crates.io :)
(Side note, we're checking if an how we can also publish this on crates.io)

Signed-off-by: Alexander Mohr <alexander.m.mohr@mercedes-benz.com
Signed-off-by: Alexander Mohr <alexander.m.mohr@mercedes-benz.com
Signed-off-by: Alexander Mohr <alexander.m.mohr@mercedes-benz.com
Side effect of this is, that the memory associated with the
context now has to be managed in rust instead of C.

Signed-off-by: Alexander Mohr <alexander.m.mohr@mercedes-benz.com>
makes enabling the trace load feature more convienient

Signed-off-by: Alexander Mohr <alexander.m.mohr@mercedes-benz.com>
Makes it more convenient to create a DLtId instance
from a string slice.

Signed-off-by: Alexander Mohr <alexander.m.mohr@mercedes-benz.com>
Signed-off-by: Alexander Mohr <alexander.m.mohr@mercedes-benz.com>
Add individual README files for dlt-sys, dlt-rs, and tracing-dlt
crates to support publishing to crates.io. Each README provides
crate-specific documentation, examples, and usage guidance.
Individual READMEs make sure, that the published artifact on
crates.io contains the correct documentation.

Update root README to serve as workspace overview with table of
crates and links to individual documentation.

Signed-off-by: Alexander Mohr <alexander.m.mohr@mercedes-benz.com>
@alexmohr
Copy link
Contributor Author

Added one more commit to split the readme files up, otherwise we wouldhave had an empty readme on crates.io (because readme key was not set in cargo.toml)
Keeping the same readme for all subprojects (by using readme = ../) wouldn't look to good on crates.io either because it would be redundant

Comment on lines 229 to 236
let get = |i| bytes.get(i).copied().ok_or(DltError::InvalidInput);

match len {
1 => DltId::new(&[get(0)?]),
2 => DltId::new(&[get(0)?, get(1)?]),
3 => DltId::new(&[get(0)?, get(1)?, get(2)?]),
_ => DltId::new(&[get(0)?, get(1)?, get(2)?, get(3)?]),
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couldn't this be simplified to:

DltId::new(bytes.get(0..len).ok_or(DltError::InvalidInput)?)

u8 should be automatically copied without the call to .copied() and the len is clamped to 1..4 anyways.
By using the get with a range we have the same safety as using the single gets I think.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That doesn't work with the current signature of DltID::new because it expects a fixed size array.

pub fn new<const N: usize>(bytes: &[u8; N]) -> Result<Self, DltError> {

But the signature is only like this because I tried to evaluate the size at compile time through making new a const fn. This didn't work like I assumed initially, so it doesn't make sense to keep the current signature.

  1. Changing the signature to pub fn new(bytes: &[u8]) -> Result<Self, DltError> {
  2. Removed the function in tracing you've commented on and added DltId::from_str_clamped instead, this is using the suggestion simplified init.
  3. (Adjusted usages)

Simplifies building the class and adds util function.

Signed-off-by: Alexander Mohr <alexander.m.mohr@mercedes-benz.com>
Copy link

@theswiftfox theswiftfox left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@alexmohr
Copy link
Contributor Author

lgtm

Thank you. I'll merge without squashing. The docs where removed in the commit which was introducing it, so it's not part of the history at all.
This way we keep at least some history instead of adding only one huge initial commit. :)

@alexmohr alexmohr merged commit a3f7916 into main Nov 28, 2025
7 checks passed
@alexmohr alexmohr deleted the init branch November 28, 2025 08:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants