@heaths I often sort of circle through bunch of languages when doing a concept. Like something started with Rust might end up being written in C or might even start with a spreadsheet :-) Rewriting is quite easy really once you have a gist of design...

Python is pretty nice for emulating a C program as you can make it call same things as with C. So I actually have like crypto libraries for trying out stuff because they have smooth API and then use something else for the end product.

@heaths I actually will use this to PoC stuff that I use kernel's crypto for so I have something quicker than e.g. libssl to get a concept :-) Not putting to production... Understand your point.

This is first pure #Rust #crypto crate that I actually like. There's been a few #libsodium alike attempts but nothing quite as good as the original. This really feels like done right: https://github.com/brndnmtthws/dryoc #rustlang

This is at least my experience: if you love your tools, you never learn to use them properly :-----)

despite all the hate speech towards #rustlang i'm working on a small and cool patch set and tooling for #rust #linux tree ;-) doing it on side but i have pretty solid idea what i want. and also is in reach of what i generally have done in kernel.

the feature has nothing to do with hard real-time operating systems but some nice patterns used by #rtic have inspired me to find a right angle:

https://rtic.rs/2/book/en/

It's cool project IMHO and nice box of ideas how to do low-level and #embedded in rust.

#rtos

@kernellogger @vbabka lol, ok ok, won't forget this i promise! 🔀 🤠

@vbabka point taken :-)

One more PR for v6.10: https://lkml.org/lkml/2024/6/5/78

#linux #kernel #tpm

Can't probably go wrong with GPLv2 I guess.

I wonder what is the policy of putting something to scripts/ (not to vmlinux) that is written with #Rust? I.e. build time utility. Just curious.

And actually, since bindgen is installed from crates.io, not from kernel tree, should it be actually submitted there, and not to the kernel tree?

Kernel documentation gives pretty bad rationale for bindgen being in Cargo: “The bindings to the C side of the kernel are generated at build time using the bindgen tool. A particular version is required.” I’m sure there are good reasons to install it using cargo but why the documentation does not list those reasons, no matter how obvious they might be to some.

So I guess I put my build time tool to crates.io because at least first it is an experiment, and secondly bindgen is managed like this. But even this does not conclude the story fully. I have no idea in what license that out-of-tree pulled build-time utility is expected to be. It is not documented, or at least I cannot find it documented anywhere.

#rustlang #linux #kernel

@jani Wow, nice list of people in the loop you have over there...

@jani @TheKeymaker And to further underline: for parts that are not obvious, there must be also a solid reason why they are not obvious. I.e. those parts exist no matter how well the semantics are implemented. Otherwise, it should not IMHO pass the patch review process in the first place... I'm not saying that accepting such functions never happens to me but this is at least the ideal...

@jani @TheKeymaker Documentation should merely document the parts that are neither obvious nor intuitive. This applies both to an inline comment and also header comment of a function...

@jani OK, did not check the implementation. I thought the point was to find the nearest power of two.

I’d probably use __fls() and << 1 unless the exact same number (i.e. already pow2). Like for the stuff I thought it was used for to be more specific… I guess I stay away from those functions, feels for me more complicated to use them than do what I want open-coded :-) Probably would end up using them in a wrong way…

Today I might start experimenting with procedural macros in #Rust, and generating opcodes with them :-)

And also keep it compiling with gccrs, if by any means possible (not going to hang myself to this tho).

#rustlang #kernel

Given how wide they are spread, neither make sense to fix the naming. Something simple like roundup and roundup_pow2 would already bring some clarity.

Ofc you could make an inline function with a "better name", which calls round_up, and let subsystems progressively transform to that but probably not worth of time and energy :-)

@jani NO. I had to check never used them. I've done round_up manually :-) Actually where I've done manual "rounding", I'd rather keep it the way it is, than switch because it makes later on easier to recall... So I have question their usefulness actually but I don't mind them being there.

OK, I guess this solves the problem: https://eips.ethereum.org/EIPS/eip-2718

So much math, too little plumbing ;-)

Other thing that puzzles in #Ethereum and #Swarm is that why waste bandwidth and CPU cycles to #JSON when you could #ASN1 the transaction like:

Root ::= SEQUENCE {
  from INTEGER
  to INTEGER
  value INTEGER
  gas INTEGER
  gasPrice INTEGER
  nonce INTEGER
  data OCTET STRING
  chainId INTEGER
}

Pretty trivial scalability optimization IMHO. Maybe I submit another talk just to say that hey use ASN1.