In various situations ability model RS-232 link for testing tools that e.g., access FPGA is an asset.

What would be a simple stochastis model that I could apply to my serial link emulator to add "realistic line noise", and don't have climb mountains to implement the algorithm?

With Rust I find the old (non-neo) vim still the most efficient text editor especially wtih complex macro declarations the static nature of the editor is an advantage.

Modern IDEs feel like ransomware. They completely destroy the screen when there's like one punctation mark missing or something and only thing that auto-complete accomplishes for me is the lost focus on task.

I tried in Sublime Text with Copilot only because Microsoft provides me a free pro license for it and it was even worse than normal autocomplete given it's wrong and fallible suggestions that completely destroy focus. I just wanted to see what it is like and it was piece of shit tbh.

Rust macros are actually a bit like "autocomplete all my objects with traits" type of tool where you write a recipe on how to auto-complete.

@cehteh sorry if I was a bit rude in my first response, i'll definitely checkout usynn once i have a chance :-) (not just saying that for plain politeness/ignorance).

@cehteh The protocol crate is in the process of scraping parsing completely as it parsing has a memory cost (it produces an object to stack) :-) But yeah, I'll check it out for expression parser once I get into doing tpm2-policy. I'm not really sure how I'm going to scope that yet.

There is a unfortunate parse which will be addressed by "migration helper trait" HasTpmCast in the follow-up commit. That is the first across the board zerocopy change.

or actually i might use some dependencies for tpm2-policy but have not decided on that so i keep it in mind :-) generally i don't prefer external dependencies as they don't translate to bootloaders, firmware and kernel.

@cehteh absolutely not, see https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/tree/src/lib.rs

still as relevant song as it was in 2014 ;-)

https://www.youtube.com/watch?v=NWxISwEBU0U

Great landed kickoff commit for casting TPM data to the main branch:

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/commit/?id=03ffb2a9fc5026dbbedd2e1bbdf52bb3cc7dc564

@Dr_Emann, and yep:

- ($ty:ty, $variant:ident) => {
+ ($ty:ident, $variant:ident) => {

EDIT: extended further to lists (and commit ID above updated) as TpmList was a pretty good test case for the trait definition itself. Luckily I had used PhantomData a few times when contributing to Enarx few years ago so I was able to make this stretch :-) Now I have like the baseline for doing zercopy in place.

This starts to “feel right” when it comes to “zerocopy”:

pub trait TpmCast<'a>: Sized {
    fn cast(slice: &'a [u8]) -> TpmResult<Self>;
    fn as_slice(&self) -> &'a [u8];
}

And pretty analogus to pre-existing TpmBuild and TpmParse i.e., they provide clone semantics and this is like hierarchical pointer.

It’s pretty easy to squeeze in because I only really have to edit macros for the most part. I have already basic types, and buffers and lists will follow the same patterns.

@cehteh yeah i know :-) i might try GNU make proc macro compilation for the sake of experiment at least. in tpm2-protocol i have everything building with make including all test programs: https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/tree/Makefile.

For this crate per se I think procedural macros would be a bad idea, it is good as it is but I might give them a shot in a crate called "tpm2-policy", which uses tpm2-protocol to create expression language for policies.

@Dr_Emann OK I tested it and it looks like it is true. Thanks for the great remark!

Still leaves me a bit confused tho of when the "real" ty fragment is the only working option

@Dr_Emann I'm building the ladders up in a separate branch first getting basic types, lists and buffers right and finding most appropriate patterns. After I have those right it is easy to populate rest of the macro generation.

E.g. first PoC TpmBuffer I have from trait instead of get(), which I likely change also in integer: https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/commit/?h=zerocopy&id=68caecf1eceac25d8f3f819ef5f7c794ffcc9177. And next thing is TpmList and then some weeks bouncing around these basic data types until they "feel" right :-)

I.e. I try to create zerocopy non-destructively without breaking the working build/parse implementation while putting this stuff in...

@Dr_Emann It's possible that I've missed something just learning by trial and error

Can you use ident to play a type e.g.,

            impl<'a> PartialEq<$ty> for TpmView<'a> {
                fn eq(&self, other: &$ty) -> bool {
                    self.get() == *other
                }
            }

If “$ty” was ident, would this work?

There's an astronomical difference between "having the same name" and "being the same".

[should be evident also from the git commit]

@Dr_Emann Absolutely 110% not as the whole point of view trait is to map a slice to a type.

Another more fun Rust related activity is figuring out how to nail batch file transfer test planning with emulated serial port that throttles the speed to a target BPS (in future also should have also signal noise emulation):

const ADJECTIVES: &[&str] = &["Quiet", "Loud", "Fast", "Slow", "Bright", "Dark"];
const NOUNS: &[&str] = &["One", "Two", "Three", "Four", "Five,", "Six"];
const EXTENSIONS: &[&str] = &["dat", "BIN", "log", "TMP", "txt"];

struct MockPort<R: Read, W: Write> {
    r: R,
    w: W,
    bits_per_second: u32,
    next_byte_due: Instant,
}

It generates 10 pseudorandom filenames and 100 KiB payloads.

Just solved a Rust sudoku for the next version of tpm2-protocol

I think this is quite clever trick to surpass some of the limitation of syntax tree macros:

macro_rules! tpm_integer {
    ($ty:ty) => {
        pub mod $ty {
            #[derive(Clone, Copy, Debug)]
            pub struct TpmView<'a> {
                pub slice: &'a [u8],
            }
        }
    };
}

Further, TpmView implements a trait called TpmView. This circulates around limitation that type cannot be used to name things in syntax tree macros.

Otherwise, unless moving into procedural macros, I’d end up ugly declarations along the lines of:

tpm_integer!(u8, TpmViewU8, Unsigned);
tpm_integer!(i8, TpmViewI8, Signed);
tpm_integer!(u16, TpmViewU16, Unsigned);
tpm_integer!(i32, TpmViewI32, Signed);
tpm_integer!(u32, TpmViewU32, Unsigned);
tpm_integer!(u64, TpmViewU64, Unsigned);

Transparency has been the single biggest blocker in moving forward with zerocopy parser and this sort of “nails it”.

EDIT

I was wrong in that you could type as module name. However, the trick does still resolve the name coflict with the original type and view type. The minor inconvience of having to repeat it twice is totally acceptable vs having to manually name stuff:

tpm_integer!(u8, u8, Unsigned);
tpm_integer!(i8, i8, Signed);
tpm_integer!(u16, u16, Unsigned);
tpm_integer!(i32, i32, Signed);
tpm_integer!(u32, u32, Unsigned);
tpm_integer!(u64, u64, Unsigned);

This is absolutely sustainable for me :-) I.e. second parameter is name of the module.

Here’s a working proof of concept: https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/commit/?h=zerocopy&id=42f61d9d85e17f784f71c8ac64ee6adbb7171997

#rust #rustlang