Jarkko Sakkinen
Posts
4871Following
323Followers
491OpenPGP: 3AB05486C7752FE1
Jarkko Sakkinen
jarkko
My favorite filesystems:
1. Ext4
2. FAT (and its various upgrades)
There's no operating system that could not read them I'm aware of.
Within last 20 years I've never had a situation where I'm in trouble because my machine does not have "advanced filesystem" :-) And basing backup strategy to local snapshots, well good luck with that. I have NAS.
1. Ext4
2. FAT (and its various upgrades)
There's no operating system that could not read them I'm aware of.
Within last 20 years I've never had a situation where I'm in trouble because my machine does not have "advanced filesystem" :-) And basing backup strategy to local snapshots, well good luck with that. I have NAS.
2
0
0
@lkundrak ok except for zmodem i'm working on "bcachefs of zmodem implementations": https://codeberg.org/jarkko/zmodem2
:-)
i might continue from that to a replacement of https://en.wikipedia.org/wiki/SMODEM, which is the competitor to the pre-existing MS-DOS version of the protocol.
:-)
i might continue from that to a replacement of https://en.wikipedia.org/wiki/SMODEM, which is the competitor to the pre-existing MS-DOS version of the protocol.
1
0
0
@lkundrak sounds like it's for smarter people than me, i would not pass the IQ test to become a legit power user of bcachefs ;-) what can you do if you're born as an idiot.
1
0
1
@lkundrak for this i chose rust because google made some nice tools for the dislayout itself: https://github.com/google/gpt-disk-rs
I was able to write a rus program that generates ESP+rootfs GPT partition layout to an image and then it with mkfs.ext4 and mkfs.fat generates partition slices of same size which I rewrite to the apprpriate slots.
I was able to write a rus program that generates ESP+rootfs GPT partition layout to an image and then it with mkfs.ext4 and mkfs.fat generates partition slices of same size which I rewrite to the apprpriate slots.
0
0
1
Jarkko Sakkinen
jarkko
does any of the ext4 crates for rust *initialize* a partition? I don't care of being able to read or write it, only "mkfs" part is interesting.
1
0
0
Jarkko Sakkinen
jarkkono SIZE constant anymore in the new TpmSized as no stack allocation is required:
/// Provides a `dyn`-safe way to get the exact size of a zero-copy cast object.
pub trait TpmSizedCast {
/// Returns the exact serialized size of the object.
fn len(&self) -> usize;
/// Returns `true` if the object has a serialized length of zero.
fn is_empty(&self) -> bool {
self.len() == 0
}
}
This ought to be renamed as TpmSized as full migration is over :-) Applies also to all other *Cast.
0
0
0
Jarkko Sakkinen
jarkko
from nothing to something type of commit considering zerocopy semantics:
https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/commit/?id=28664f46cdcf2c5527d0c3e409a292dad2501bba
now it will be downhill :-)
#linux #rust #tpm
https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/commit/?id=28664f46cdcf2c5527d0c3e409a292dad2501bba
now it will be downhill :-)
#linux #rust #tpm
1
0
0
Jarkko Sakkinen
jarkko
i've finally found my preference for command line arguments in rust: argh. it's like "between the extremes". does not get in the way but neither does "overdo"
0
0
0
Jarkko Sakkinen
jarkko
i created an experimental "slice and compose" style disk image builder just to build appropriate EFI bootable disk images for kernel testing. i might release this at some point once it "productizes"
0
0
1
And once the disease is spread fully, "parse" and "build" become unnecessary. Bytes are the type and "build" is `as_slice`. Most likely 0.11 size will shrink from the current 8K line to something like 5K once all of this is done. It's a pretty decent number taking into account that the care is fully self-contained with no external dependencies.
This makes me think what's really the point of using "higher level" framework like TSS2 after one has more idiomatic and easier access to the actual core architectural type ... It's pretty quick to build resource managers and stuff like that on need and per application after you have such a tool.
In some ways this does rise an existential challenge to pre-existing sofware stacks, at least to the level that I personally rather build more software around this core than have focus on getting tpm2-protocol integrated anywhere really. I have MockTPM in good progress and some pieces for tpm2-policy module. I guess you can call that an "SDK" or something.
This makes me think what's really the point of using "higher level" framework like TSS2 after one has more idiomatic and easier access to the actual core architectural type ... It's pretty quick to build resource managers and stuff like that on need and per application after you have such a tool.
In some ways this does rise an existential challenge to pre-existing sofware stacks, at least to the level that I personally rather build more software around this core than have focus on getting tpm2-protocol integrated anywhere really. I have MockTPM in good progress and some pieces for tpm2-policy module. I guess you can call that an "SDK" or something.
0
0
0
Jarkko Sakkinen
jarkko
Even tho still only "compile-tested" code the from_slice implementation in TpmList and associated iterator is enough evidence that the approach is in fact effective:
https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/tree/src/list.rs
https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-protocol.git/tree/src/list.rs
1
0
0
Translates pretty well (from_slice is lacking some RC related checks just PoC code):
pub struct TpmRcCast<'a>(TpmUint32<'a>);
impl<'a> crate::TpmCast<'a> for TpmRcCast<'a> {
fn from_slice(slice: &'a [u8]) -> TpmResult<Self> {
Ok(TpmRcCast(TpmUint32::from_slice(slice)?))
}
fn as_slice(&self) -> &'a [u8] {
self.0.as_slice()
}
}