@bluca OK thasnks, I can clone that and check:

1. git clone systemd
2. export SYSTEMD_OVERRIDE_SRCDIR=$PWD/systemd

Then cherry-pick the patches… I want to pick over 255 because last version with all the legacy and it is BuildRoot in question (not necessarily fully systemd unity compatible).

Trying to deploy #systemd to BuildRoot build:

Filesystem found in kernel header but not in filesystems-gperf.gperf: BCACHEFS_SUPER_MAGIC                                                    
Filesystem found in kernel header but not in filesystems-gperf.gperf: PID_FS_MAGIC                                                            

I think I might know how to fix these tho so should not be an issue.

I had QEMU style build. I’m repeal and replacing that with a build that builds 2GB disk image ESP/UEFI compatible. That can then supplied to qemu/libvirt or burned to stick and booted with hardware.

#linux #kernel #testing

@vbabka Like https://www.microsoftpressstore.com/store/code-the-hidden-language-of-computer-hardware-and-software-9780137909100

I did read the first edition years ago :-)

Don't get too excited: Intel TXT will be also available in #x86s ;-)

Unfortunately this is not documented yet in Intel SDM , which misguided a bit when I was reviewing Trenchboot.

Finally I found [1], which has a "3.15 SMX Changes" section and asociated pseudocode Hopefully soon also in the SDM.

So long live measured DRTM launch ;-) The future is now.

[1]
https://lore.kernel.org/linux-integrity/D1SPFVXS6FOG.IQQB3INFYEF2@kernel.org/
[2]
"X86S EXTERNAL ARCHITECTURAL SPECIFICATION"
https://cdrdv2.intel.com/v1/dl/getContent/776648

#linux #kernel #x86

@pinkforest Right and obviously you can use mmap() in addition to extend and truncate the address space on the run. FALLOC_FL_PUNCH_HOLE just removes page from reserved set, and does not unmap page. As soon as it is accessed a new page is created the of course in this case. So anyway, there is all of this really nice stuff just in plain Linux uapi that you can use to do amazing things with memory, and de-facto Rust installation is totally unaware of their existence. Quite lame to put it as I really think it is :-)

@pinkforest Like for instance. What would you possibly do with a re-allocating vector in any modern systems software? For small chunks, create large enough fixed arrays. For data that needs to scale dynamically however many gigabytes of addresses can be mapped with a total zero cost, and the #PF handler takes care of the rest. Finally there is an option to manually scale the space down with fallocate() (FALLOC_FL_PUNCH_HOLE).

This is standard stuff in modern C systems software. If this is over the top, then I tend to think that probably Java or Go would be better picks in the first place.I just use Python then because more than liking a tool, I like measurable value, which cannot be just my liking. Self-deception IMHO :-)

Over the years best things that have came out from #Microsoft that I've liked have been from Microsoft Press :-) IMHO, the best subsidiary of Microsoft.

@pinkforest Anyway, I have a small little project to work on where macros in Rust work great :-) Also small set of dependencies I'd like to see it compiling gccrs and rustc and find ways to keep that constraint. Probably have something together in August.

Yeah well the language itself is nice and especially when fallible alloc's are a stable feature :-) And I'd expect that there will be clippy switch to make them enforced if you want... so things will get fixed eventually.

@heaths I actually also think that Rust's stdlib is quite bad.

Rust is a modern language, and e.g. I like the idea of procedural macros. But why create standard library, which takes greatest hits of 80s POSIX tape-drive alike File API and container types from 90s Java that I don't get.

It was pretty apparent in 2016 that you mostly just map memory, and storage is non-volatile RAM. There's lot of these types of contradictions in Rust, and variance in stock API quality.

Personally I use this as my basic memory API https://github.com/rust-vmm/vm-memory, and more like to to this direction should have been I/O API design of stdlib in 2016 (despite being part of rust-vmm, it can do all types of mmaps).

Not even joking when I say that this my favorite part of Rust's stdlib: https://doc.rust-lang.org/std/marker/struct.PhantomData.html. This one I do like.

The comment about crypto library is IMHO even more to the point given that not only Rust was designed with the borrow checker but it was also made by Mozilla for use in Web Browser development. The first presentation I saw about Rust was at LinuxCon EU 2014, and it was more about Servo than Rust itself.

@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