Posts
4937
Following
327
Followers
492
Linux kernel hacker and maintainer etc.

OpenPGP: 3AB05486C7752FE1

Jarkko Sakkinen

With these I wonder "why even bother" o_O
1
0
1
Personally I think that it would make a lot of sense to have this type of meta-data in DNS attributes. I.e. some means to say that this IP is a blockchain node and the type of the blockchain. Not much else but it could help a lot with low cost.
0
0
0

Jarkko Sakkinen

Edited 9 months ago
I've talked to my colleagues that one thing that strikes me in presentations given about any blockchain technology, is that they have a problem that the presentation goes straight into cryptography and smart contracts.

What you *actually* should start with is how the network discovery works. I.e. plain and simple how network nodes find each other. It's not flashy but it is like the first question for any seasoned engineer.

In order to do the secret handshakes you need to first bump into someone else to do your dance.
1
0
0
@cesarb @pid_eins Also even if all those procedure were taken care of (rescue password locked into PCR's), I would never use a computer, which has been physically compromised. A physical compromise is a game over as far as I'm concerned, and TPM's work best against software attacks :-) That has been the driving design goal in the standard.
0
0
0
@cesarb @pid_eins For my home desktop I would never lock password into the PCR's, i.e. that really should be a choice. Depends on deployment really.
1
0
0
@ljrk @pid_eins Thanks for all the feedback on this (from everyone who comments, all comments were useful).

I posted this mainly because could not get the gist, and was wondering do I have some blind spot here, that's all.

There's like a drum roll but no drop...
0
0
1
@pid_eins This was circling around social media, I read it 3~ times, and could not catch the dragon tail...

The only thing I also did catch was that "PCR 7 locking is unsafe", which is obviously dead obvious, so I guess this is noise about nothing then :-)
0
0
0

Jarkko Sakkinen

Edited 9 months ago
Multiple capture/output devices issue in the OOT driver and v4l2-loopback. It has the unfinished "SPLIT_DEVICES" compilation options, which I DO NOT fully cope with. I don't get what the heck they are aiming for TBH.

A video device can be either something like camera or something that takes input from client and displays that, e.g. similar device to ChromeCast would be a good example in this context.

I'm aligning to a solution where the initial "ADD" ioctl has:

1. flags (for setting the RW properties)
2. video_nr
3. video_fd (for server to read OR write)

And the direction is determined by flags. I did not fully understand why OOT driver aimed to do both capture and output device simultaneously, which does bother me a bit since it would be best to know the original reasoning, even if the conclusions were wrong.

Moving slowly in this area still and experimenting with options.

#linux #kernel #media #video4linux
0
2
1
awesome, at least it is a pass (did not test before wrote that) :-) so a baby step, but one forward...
1
0
0

At least something done in the kernel side for the v4l2-loopback driver this week:

  1. The first baby step towards anonymous inode based loopback device: https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/commit/?h=v4l2-loopback&id=90235ae07630962e6dc7c6b2b67f9e94584a6b74
  2. And a reflective step in my test program: https://codeberg.org/jarkko/v4l2-loopback-test/commit/8950e975817e9d9b8012880dd9f2443d2fe13c77

The next small push is to split v4l2_loopback_fops into two: one for /dev/videoX and other for the anonymous inode returned back from the ioctl.

#linux #kernel #media

1
1
2
Edited 10 months ago

Got tired of updating clangd data manually so did a quick script to automate it :

#!/usr/bin/env bash
# Copyright (c) Jarkko Sakkinen 2025

set -e

run_build() {
  make ARCH=x86_64 O=.clangd -j$(nproc)
  scripts/clang-tools/gen_compile_commands.py -d .clangd
}

run_menuconfig() {
  if [[ ! -d .clangd ]]; then
    exit 1
  fi
  make ARCH=x86_64 O=.clangd menuconfig
  run_build
}

while getopts ":m" opt; do
  case $opt in
    m)
      run_menuconfig
      exit 0
      ;;
    *)
      echo "Usage: $0 [-m]"
      exit 1
      ;;
  esac
done

if [[ ! -d .clangd ]]; then
  make ARCH=x86_64 O=.clangd tinyconfig
fi
run_build

#linux #kernel #clangd

0
1
0
Reported to rust-lang/rust if anything to get some ideas how to fix this in the downstream:

https://github.com/rust-lang/rust/issues/135704

It's weird...

#rust #rustlang
0
0
2
@pid_eins any thoughts on this one?
2
0
0
Related to the recent #LWN article: can Sequoia already all kernel maintainer workflows or not?
0
0
0

It feels suboptimal that each fedi service requires a different account.

e.g. I have a Flohmarkt instance, which is different from my Mastodon instance. If I also ran a pixelfed instance, that would be a third account.

Rather than one "me", with different linked services.

Perhaps there is a need for a fedi directory service / "main" account, which people can use for discovering of sub-accounts?

(I can see that, for some users, separation of accounts will be valuable, so I wouldn't want to remove that ability.)

11
2
0
Edited 10 months ago
C library and Rust crate recommendation of the day:

1. C: https://github.com/emoon/minifb
2. Rust: https://github.com/emoon/rust_minifb

This is pure gold!

A simple no bullshit framebuffer that dumps to X11/Wayland/macOS/iOS/Android/Web(WASM).
0
1
3
Show older