@arj OK, cool, just giving evidence that there's no bottleneck to add more support, only four relatively simple steps :-)

@arj ARM support can be added but not in the scope of my patch set. The priority is to implement it so that arch support can be gradually added.

Post this work ARM support could be added by:

1. Implement alloc_execmem().
2. Implement free_execmem().
3. Edit appropriate arch Makefile.
4. Set HAVE_ALLOC_EXECMEM in appropriate Kconfig.

Kprobes w/o modules for RISC-V v5

https://lore.kernel.org/linux-riscv/D036FYBQUMIX.L5TL0SUCAO49@kernel.org/T/#t

s/textmem/execmem/ (a typo)

#linux #kernel #kprobes #riscv

@ncopa Hey thanks a bunch!

@merri must be true if you say so but i have zero interest in politics.

Does anyone provide static and pre-compiled #busybox binaries for #riscv? For #x86 busybox.org provides this but other than that I have no idea.

I guess the software version of Moore's law is that software gets exponentially worse as hardware gets exponentially better. For instance, word processors do mostly the same tasks as in 1993 but do not run with 386 and 4 megabytes of RAM :-)

#amiga #sampler https://www.potenzadsp.com/amigo/

#audio

@viznut @neauoire it is also style adopted by various plugin systems like audio plugins (VST, AU etc.) where you need immediate mode GUI that is driven by the plugin callbacks (most of operating system UI framework are incompatible how plugins behave).

Not my expertise area at all but I was just thinking how would you measure relative round-trip time of syscalls on let's say between x86 and RISC-V. i.e. when you have your measurements how would you normalize the results for meaningful comparison.

I tried to switch back to mutt couple of times but aerc some tricks under its sleeve that have kept me using it.

After about two'ish years of use I've reached the point with #aerc #email client that I do not pro-actively hate it :-)

The withdrawal symptons of #mutt are over...

@jon_giraffe or if you want to go crazy:

$ alias rustup-init="curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s --"
$ rustup-init --help
rustup-init 1.27.0 (b02c9c2b4 2024-03-08)

The installer for rustup

Usage: rustup-init[EXE] [OPTIONS]

Options:
  -v, --verbose
          Enable verbose output
  -q, --quiet
          Disable progress output
  -y
          Disable confirmation prompt.
      --default-host <default-host>
          Choose a default host triple
      --default-toolchain <default-toolchain>
          Choose a default toolchain to install. Use 'none' to not install any toolchains at all
      --profile <profile>
          [default: default] [possible values: minimal, default, complete]
  -c, --component <components>...
          Component name to also install
  -t, --target <targets>...
          Target name to also install
      --no-update-default-toolchain
          Don't update any existing default toolchain after install
      --no-modify-path
          Don't configure the PATH environment variable
  -h, --help
          Print help
  -V, --version
          Print version

Execution of a remote payload but should be fairly secure as it is verified with rust-lang.org CA (thanks to TLS 1.2).

@jon_giraffe for more options:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | bash -s -- --help

#Rust installation instructions go like:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

But what you actually want to do most of the time, is probably:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | bash -s -- --no-modify-path

#rustlang

@orsinium So I did look into it a bit and if I got the right understanding it has its own backing storage thing.

So my thought are that:

• A more stream-lined interface for OpenPGP keys would be more than welcome.
• That said it should be able to fully connect to the existing GnuPG infrastructure because of compatibility sake. It would be tedious to switch whole “ecosystem” just for a better command-line tool.
• As long as the tool takes care of the shenanigans it does not matter how complicated the storage format is.

I.e. if I have a fresh GNOME desktop it already has gpg-agent ongoing with zero configuration (thanks to systemd). So by all practical means the backend side is sort of almost defacto standard.

Great, got it working:

• https://lkml.org/lkml/2024/3/24/14
• https://lore.kernel.org/all/D01IRZK3V45H.3594SKXE83TN9@kernel.org/T/#t

#linux #kernel #kprobes #riscv

@orsinium Right one other thing is that any tool must by practical means be compatible with gpg-agent. I'm voting for better interface but because of incompatibility issues it actually would be better off if it could persist to the gnupg's backing storage. This for compatibility with session managers, gpg-agent and all sorts of GUI applications dealing with OpenPGP keys.

It's my old #kprobes fix but scaled down to only riscv: https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/commit/?h=kprobes-v2&id=751d26b0addddf0470f6a9383e7da4b3d23b8b4e

Note that I've not even compile-tested this yet, i.e. due to changes still.

Yes, something like kprobes_alloc perhaps could make sense but I see the scope of patch sane: it does a necessary evolutionary step towards more logical separation.

making my first arch/riscv patch ever :-) nothing flashy but you have to start from something in everything… #linux #kernel #riscv