DEV Community: Luca Barbato

winnow-args 0.5.0

Luca Barbato — Sun, 25 Oct 2026 14:20:17 +0000

I spent a bit more time working on winnow-args. I improved it after trying to integrate it with brush, maki, em.

What changed

Mainly I expanded a bit relations between fields and groups to address what maki needs, improved the subcommand and multicommand support in preparation to em release and fixed more corner cases in brush improving winnow-args in the process.

Now we are closer to have feature parity with usage and clap but the road is still long.

The early adopters that used the derive API do not have to change anything in their code.

Feature	0.2.0	0.3.0	0.4.0	0.5.0	usage 7	clap 4
Errors and rules
"Did you mean" tips	✓	✓	✓	✓	✓	✓
Every missing required argument reported at once	–	–	✓	✓	✓	✓
`required_if`, `required_unless_all`	–	0.3.1	✓	✓	✓	✓
`required_if_all`	–	–	✓	✓	✓	✓
`requires_if`, `exclusive`	–	0.3.1	✓	✓	✓	✓
`requires` naming a group	–	–	✓	✓	?	✓
Own message for a conflict or requirement	–	–	✓	✓	–	–
`validate`, a check on the parsed struct	–	0.3.1	✓	✓	✓	~
Values and defaults
`from_str`, a value parsed by `FromStr`	–	✓	✓	✓	✓	✓
`default_from`, a default made from other fields	–	0.3.1	✓	✓	✓	~
A bare `env`, named after the field	–	–	✓	✓	?	✓
A repeated `default` on a `Vec`	–	–	✓	✓	?	✓
`bool_value` (`--wait=false`)	–	–	✓	✓	✓	~
`value_names` (`--point <X> <Y>`)	–	–	✓	✓	✓	✓
`env_fallback`, more variable names	–	–	–	✓	✓	–
Subcommands
Generated dispatch (`run`, `run_async`)	0.2.1	✓	✓	✓	✓	–
A flag that selects the default subcommand	0.2.1	✓	✓	✓	✓	–
Global flags in a flattened struct	0.2.1	✓	✓	✓	✓	✓
A subcommand variant with named fields	–	✓	✓	✓	✓	✓
`default_subcommand_on_empty`	–	0.3.1	✓	✓	✓	–
External subcommands	–	–	✓	✓	✓	✓
Multicall	–	–	✓	✓	✓	✓
Help
`emphasis` and `strong` painted	✓	✓	✓	✓	?	–
Global flags listed in a subcommand's help	–	✓	✓	✓	✓	~
Default subcommand marked, its page after the root's	–	✓	✓	✓	✓	–
Examples	–	✓	✓	✓	✓	~
A paragraph under a heading	–	✓	✓	✓	✓	~
A flag's `warning`	–	✓	✓	✓	✓	–
`flatten_help`	–	✓	✓	✓	✓	✓
`hide_default_value`, `hide_env`, `display_order`	–	0.3.1	✓	✓	✓	✓
`verbatim_doc_comment`	–	–	✓	✓	✓	✓
Width in terminal columns (`unicode`)	–	–	✓	✓	✓	✓
`visible_alias`	–	–	✓	✓	✓	✓
`long_version`, `before_help`, `usage`	–	–	✓	✓	✓	✓
What each choice means	–	–	–	✓	✓	✓
`hide_choices`	–	–	–	✓	✓	✓
`help = CONSTANT`	–	–	–	✓	–	✓
`brief_help`: `--help` prints the short page	–	–	–	✓	–	–
Deprecation
Deprecated flags, positionals and subcommands	–	–	–	✓	✓	–
`deprecated_warn_at`, `deprecated_remove_at`	–	–	–	✓	✓	–
`deprecated_env`	–	–	–	✓	✓	–
Completion and pages
Completion of a value by hint or function	✓	✓	✓	✓	✓	~
Man and markdown pages	✓	✓	✓	✓	✓	~
Effects, outputs, exit codes in the pages	–	✓	✓	✓	✓	–
A page for each multicall command	–	–	✓	✓	?	–

Here some more details

Errors and rules

An unknown flag, subcommand or value now comes with a tip for what was probably meant (0.2). The search runs only once there is an error, so a correct command line pays nothing for it.

When several required arguments are missing, they are all reported at once, each as --help lists it (0.4).

The rules gained most of what clap has: required_if,
required_unless_all, requires_if and exclusive (0.3.1), and
required_if_all, plus requires naming a group (0.4). conflicts, requires and groups take a message with the program's own wording.

For anything the attributes can't express, validate = function runs the program's own check on the parsed struct.

Values and defaults

We have new attributes to parse the cli values to types:

from_str parses a field with its type's FromStr, for a type from another crate (0.3).
default_from makes a default from other fields, after their own defaults (0.3.1).
bool_value takes --wait=false, and value_names gives a flag several placeholders, --size <W> <H> (0.4).

A bare env reads the variable named after the field, and a Vec can repeat default (0.4). env_fallback reads more variables after env (0.5).

Subcommands

Most of it came with the effort to support completely all I need for em.

With default_subcommand_flags, a flag the root doesn't take selects the default subcommand, so

$ em -pu @world

Maps automatically to:

$ em emerge -pu @world # (0.2.1)

default_subcommand_on_empty runs it for a line with no command at all (0.3.1).

A subcommand can be a variant with named fields (0.3), and a flattened struct can hold global flags (0.2.1).

#[arg(run)] on an enum of subcommands generates the dispatch to the command it holds (0.2.1).

multicall makes one binary act as each of its subcommands when it is run under that subcommand's name, the way busybox's applets work (0.4).

Help and errors use the name it was run as. #[arg(external)] on a variant takes any word that names no other subcommand, plus the rest of the line, the way cargo foo runs cargo-foo.

Help

winnow-args starting point was to get the best possible performance, but having nice help does not impair this need so I tried to make it as expressive as possible.

Help has examples, a paragraph under a heading, and a flag's warning (0.3).

A subcommand's help lists the global flags it inherits, and the default subcommand is marked, with its page after the root's. *emphasis* and **strong** spans are painted (0.2), and an example's line is painted word by word (0.3.2).

0.4 added verbatim_doc_comment, widths in terminal columns
under the unicode feature, visible_alias, long_version, before_help and usage.

Help can say what each choice means (0.5). A ValueEnum variant's doc comment, or choices("fast" = "…") on a field, is listed one value a line by --help, while -h keeps the short [possible values: …].

A hand-written FromArg can answer from data only the running program has; brush uses this for the complete -A and -o choices, whose meanings live in brush-core.

0.5 also added hide_choices, help = CONSTANT, and brief_help, which makes --help print the short page.

Deprecation

A flag, a positional, a subcommand or an environment variable can be marked deprecated (0.5). Using one prints a warning.

deprecated_warn_at keeps the warning quiet until a later version, and deprecated_remove_at says when it goes away.

deprecated_env covers a variable that has been renamed.

Args::parse prints the warnings; Args::warnings returns them to a program that wants to report them itself.

Completion and pages

A value is completed by a hint, hint = "dir", or by the program itself, complete = function (0.2).

The completion script asks the program, so it always matches what the program accepts.

With WINNOW_ARGS_SPEC set, the derives write a TOML description of each type at compile time (0.2). winnow-args-man and winnow-args-markdown turn those descriptions into pages.

The program is only checked, never run, so the pages can be made for a target that can't run on the build host, this addresses one of the papercut that comes from generating man and completion from the cli.

Since then the pages have picked up examples, headings, effects, outputs and exit codes (0.3), a page for each multicall command, ls.1 rather than box-ls.1 (0.4), and deprecations (0.5).

Coming next

I'll keep improving the crate aiming to reach feature-parity (see the checklist tracking the features), you are welcome to use it, find bugs and send patches as usual.

winnow-args: yet another args parser

Luca Barbato — Tue, 13 Oct 2026 05:11:14 +0000

winnow-args is a command line parser for Rust, built on winnow.

Why another one

There are plenty of great crates already, why adding one more given that you have clap, bpaf and usage?

All of them are quite good for different purposes:

clap is pretty much the standard, quite user-friendly, but bit slow and not as flexible as you want once you need to parse something more than the usual --long, -l options.
bpaf is way more flexible, but not built for speed.
usage-rs has a very interesting approach to get the best performance while having as many features as clap.

Sadly the 3 do not have at the same time the flexibility and speed I need.

Speed on the cli?

In brush, every builtin is a small command line: set -eu, declare -x NAME=value, printf -v var '%s' x.

A script runs thousands of them, so the parser runs thousands of times in one process, and a parser that builds its
description of the command at each call is paid for at each call.

Builtins also have to support patterns that are not so common, e.g: set +x turns off what set -x turns on.

I'm using brush extensively in my portage rewrite to parse ebuilds, anything that gets me a bit of speed is welcome.

How can a cli be annoyingly irregular?

One of the most annoying and yet widely used cli syntax is the one used by the GNU linker and thus supported by lld, mold and wild.

Since I started looking at supporting more special pattern I decided to tackle also that. Sadly the mold author prefers the current bespoke solution at least so far.

Here few examples on how irregular it can be:

ld -shared -o out.so --as-needed -lc a.o -z now

long options with one dash: -shared
short options with arguments: -o and -z
flags whose order matters: --as-needed applies to the libraries after it.

And it can get even more complex.

winnow-args

Under the hood it leverages winnow zero-copy combinators over a slice of &OsStr, that maps neatly with the native BStr provided.

To make it easier to use a derive is provided in a fashion similar to the other crates.

A struct is a command line.
A field in the struct is a flag or a positional, its doc comment is its help.
Enums can be used to express possible values or subcommands.

Here some examples:

mini-mise

This example uses subcommands, aliases, dynamic custom values, examples, runtime completion support and colored help.

use winnow_args::color::{Color, Paint, Palette, Theme};
use winnow_args::complete::{Candidate, Shell};
use winnow_args::{Args, Subcommand, ValueEnum, report_with};

/// Install and run development tools
#[derive(Args, Debug)]
#[arg(
    name = "tool",
    version,
    default_subcommand = "use",
    example("tool use -g node@22", header = "Install a tool for every project"),
    example = "tool ls --json"
)]
struct Cli {
    /// Show more (repeat for more)
    #[arg(short, long, count, global)]
    verbose: u8,
    /// When to use color
    #[arg(long, global, default = "auto")]
    color: When,
    #[arg(subcommand)]
    command: Command,
}

#[derive(ValueEnum, Debug, Clone, Copy)]
enum When {
    Auto,
    Always,
    Never,
}

#[derive(Subcommand, Debug)]
enum Command {
    /// Install a tool and add it to the project
    #[arg(alias = "u", example = "tool use node@22 python@3.13")]
    Use {
        /// Use the global config instead of the project's
        #[arg(short, long)]
        global: bool,
        /// How many downloads run at once
        #[arg(short, long, default = "4", env = "TOOL_JOBS")]
        jobs: u32,
        /// What to install, as `name@version`
        #[arg(positional, required, complete = tools)]
        tools: Vec<String>,
    },
    /// List installed tools
    Ls {
        /// Print JSON
        #[arg(long)]
        json: bool,
    },
    /// Remove a tool
    #[arg(alias = "rm")]
    Remove {
        /// The tool to remove, as `name@version`
        #[arg(positional, complete = tools)]
        tool: String,
        /// Remove it even if a project uses it
        #[arg(short, long, warning = "Projects that pin it will stop working.")]
        force: bool,
    },
    /// Print a completion script
    Completion {
        #[arg(positional)]
        shell: Shell,
    },
}

/// What a shell offers for a tool, given what is typed of it.
fn tools(typed: &str) -> Vec<Candidate> {
    ["node@20", "node@22", "python@3.13", "ruby@3.4", "zig@0.15"]
        .into_iter()
        .filter(|tool| tool.starts_with(typed))
        .map(|tool| Candidate {
            value: tool.to_owned(),
            help: "",
        })
        .collect()
}

fn main() {
    let args: Vec<_> = std::env::args_os().skip(1).collect();
    if let Some(answer) = Cli::completion_request(&args) {
        print!("{answer}");
        return;
    }
    let cli = match Cli::parse_from(&args) {
        Ok(cli) => cli,
        // Help and version end up here too: `report_with` prints and says how to exit. The theme() implementation is further below.
        Err(error) => std::process::exit(report_with(&error, "tool", &theme())),
    };
    if let Command::Completion { shell } = cli.command {
        print!("{}", Cli::completion_script(shell));
        return;
    }
    println!("{cli:#?}");
}

Help, from the doc comments

-h is the summary and --help the whole text. A subcommand's page lists the global flags it
inherits, a flag can carry a warning, and the examples are declared, not pasted into a string.

Palettes and themes

Help and errors are painted from a palette, and the terminal says how deep it goes: no color in a pipe or under NO_COLOR, the 16 basic colors, 256, or 24 bits.

A theme is a palette for each depth.
The default one, on a 16-color and on a 256-color terminal:

With NO_COLOR=1, or in a pipe:

A program brings its own with a few lines. Here one palette for 24-bit terminals, and clap's look for people who are used to it:

/// The paints of help and errors: `TOOL_THEME` picks one.
fn theme() -> Theme {
    const fn rgb(r: u8, g: u8, b: u8) -> Paint {
        Paint::fg(Color::Rgb(r, g, b))
    }
    // On a 24-bit terminal only; the others keep the default palettes.
    const SUNSET: Palette = Palette {
        header: rgb(255, 158, 100).bold(),
        flag: rgb(224, 175, 104).bold(),
        command: rgb(224, 175, 104).bold(),
        placeholder: rgb(187, 154, 247),
        default: rgb(247, 118, 142),
        choice: rgb(247, 118, 142),
        ..Palette::DEFAULT_256
    };
    match std::env::var("TOOL_THEME").as_deref() {
        // clap's own look: bold and underline, color only in errors.
        Ok("clap") => Theme {
            ansi16: Palette::CLAP,
            ansi256: None,
            truecolor: None,
        },
        Ok("sunset") => Theme {
            truecolor: Some(SUNSET),
            ..Theme::DEFAULT
        },
        _ => Theme::DEFAULT,
    }
}

Extended error reporting

Completion that asks the program

tool completion fish prints a short script that calls the program back, so the shell always offers what this build of the program takes.

Flags come with their descriptions, a value with its choices, and complete = tools above hands the question to a function of yours.

bash, zsh, fish, elvish and PowerShell are supported.

Exotic syntaxes

-eu +x is three fields of type Option<bool>, each declared #[arg(short = 'e', plus = 'e')].

The linker's flags are an enum, and the struct holds them in the order they were given.

Under the hood

The derive produces the following:

the parser
the help as static data
optionally a toml description.

At run time the words go through a small lexer, the generated parser binds each to its field, FromArg turns a word into a
value, and a last step applies the environment, the defaults and the rules between fields.

Help, the tips in errors and completion all read the same static data, and only when needed.

The toml descriptions are needed by the documentation builders. They read the files the derive writes on request and they do not depend on running the code generated for the target architecture.

Key features

The parser is generated at compile time. The derive writes a match over the flags of your struct. Nothing is assebled when the program starts, so a program with two hundred subcommands starts parsing as fast as one with two.
Words are borrowed. Nothing is copied or re-split, and the bytes need not be UTF-8 until a field's type asks for text.
Mistakes in the declaration are compile errors. A conflicts("nme") that names no field, two flags with the same letter, a positional after a list that takes every word: the build fails.
Help is data. The prose sits in read-only memory until --help asks for it, and a feature leaves it out of the binary altogether if it is not needed.

Everything is a winnow parser, so you can build your own by combining the basic parsers together manually.

Performance

winnow-args is built essentially for speed first, comfort as close second.

The repository has two benchmarks used to make sure adding features won't cause slow downs.

It compares with the other argument parsers I normally use:

	a small CLI	mise's 211 commands
winnow-args	187 ns	327 ns
usage 7	516 ns	767 ns
clap 4	15.0 µs	757 µs
bpaf 0.9	14.8 µs	2.65 ms

The same command lines are written once per framework in the repository's benchmarks/.

A program that parses once will not feel the difference with clap on a small command line. A shell does, and so does a tool with as many subcommands as mise.

Implemented features

A good deal of features are already implemented, but some found on more mature parsers are still missing.

	winnow-args	usage	clap
Flags, values, positionals, subcommands, global flags, `flatten`	✓	✓	✓
Conflicts, requirements, groups	✓	✓	✓
Help from doc comments	✓	✓	✓
Completion scripts	✓	✓	~
Parser generated at compile time, words borrowed	✓	✓	–
Combinators, without a macro	✓	–	~
`+x` options, as a shell builtin takes	✓	–	–
Long options with one dash, `-z` keywords, as GNU `ld` takes	✓	–	–
Flags kept in command-line order	✓	~	~
Flag constraints checked at compile time	✓	–	–
Help prose left out of the binary by a feature	✓	~	–
A CLI built at runtime, external subcommands	–	✓	✓
Conditional requirements (`required_if`)	–	✓	✓
Man pages, markdown	~	✓	~
"Did you mean" suggestions	✓	✓	✓

winnow-args-man and winnow-args-markdown render one page per command.

They do not run the program to build it:

when WINNOW_ARGS_SPEC set, the derives write a description of each type while cargo check or cargo build expands them.
the pages are built from those files.

So man pages can be built correctly even when cross compiling.

In closing

With version 0.3.0 winnow-args graduated from being a quick experiment to see how far I could push the parsing performance and now it can be used to deal with the quirks of complex CLIs.

Some features that I didn't need to support brush and portage-cli em are still missing and I have plans to add a more flexible generator based on minijinja, but I welcome you to try it and possibly provide feedback and pull requests to improve it further.

pseudoroot, fakeroost, hakoniwa... How to deal with unpriviledge packaging?

Luca Barbato — Sat, 04 Jul 2026 17:52:23 +0000

em is progressing nicely, to the point that it is now very close to produce a correct stage1 from scratch.

Since one of the additional design constraint for portage-cli is that I want to be able to keep everything as unprivileged as possible, now it is time to tackle that annoying bit.

Build systems and root privileges

Most packages usually do not care at all about having privileges, they build as whichever user you are, as long the build and install directories are writable.

Some need something more because at the install phase they need to create device files using mknod or just they want to have dedicated users.

Nice build systems may let you override the root-only bits or just disable them, that's what linuxbrew tends to leverage. But since the plan is to produce complete Gentoo stage3 and not just user-install packages this isn't an option.

To root or not to root

The traditional way get away with that is either become root using sudo for the install phase and be done with that, relying on some kind of sandboxing to avoid surprises.

Another path is to simulate being root without being it, fakeroot is a good example of this approach.

A third way sort of in between, that I'm using in crossdev-stages already, is to leverage more modern linux features to have both sandboxing AND the illusion of being root. hakoniwa and bubblewrap are the best tools to achieve that.

Faking root

When dealing with simulating being root one of the details to consider is how much overhead this adds.

We are using this while building software and this is already time consuming in itself.

LD_PRELOAD

The venerable approach is to just rely on the dynamic linker to interpose over the libc functions we care about (stat, mknod and so on) patch its argument and keep track of the fake creations so when its time to package the files the correct users and permissions are recorded.

This works as long as:

The binary is dynamically linked
The dynamic linker listens to you
You interpose all the functions used in the binary (e.g. stat64 vs stat)

That on Linux distributions is generally the case, but since statically linking is back fashionable we might not want to bet on it.

It has potentially among the least amount of overhead as long as the permission/ownership accounting does not get in the way.

ptrace

If you have to deal with the corner case an approach is to rely on ptrace and do the patching at the syscall level.

This has an higher overhead compared to alternatives, but if we are on Linux, seccomp lets us be more selective, but still the per-call overhead is much larger. Since on macOS it became impractical to use, it also has portability concerns.

Linux namespaces

Linux namespaces make easy to simulate the user id (by having subid offsets) and it is pretty much 0 overhead.

The only problem is that to avoid leaving a large security hole mknod cannot create new devices in the sandbox produced, so it isn't a full solution if we aim to cover also that specific bit of the image/package creation story.

So far

I released pseudoroot since it is already overall nicer and faster than the alternatives and provides enough coverage.

I'm still contributing to fakeroost trying to make it faster even if it works only in Linux, since you never know when static build systems might appear, even if a sandbox based on Landlock and Seatbelt might complete the picture keeping the overhead hopefully low.

portage-cli

Luca Barbato — Sat, 20 Jun 2026 08:58:10 +0000

I'm experimenting with an alternative implementation of portage in Rust.

It is quite different from pkgcraft even if both projects have similar targets.

Main differences:

separation of concerns: portage-cli is based on a set of layered crates, that let people reuse specific parts of it. pkgcraft on the other hand is a bit monolithic right now.
pure-rust: pkgcraft for correctness wraps bash, portage-repo leverages brush fixing issues as they are found.
focus on different tooling: pkgcraft offers already extensive linting support via pkgcruft, portage-cli offers an emerge workalike (em) with a pubgrub-based dependency resolver.

Some numbers

Some comparisons with the current implementations.

metadata regen

All 3 tools are able to do that and we have a script to do that in a simple way.

GENTOO_REPO=/var/db/repos/gentoo \
EM=target/release/em \
PK=../pkgcraft/target/release/pk \
INCLUDE_EGENCACHE=1 \
ITERATIONS=1 \
./benchmarks/scripts/compare-regen.sh 8 16 20 24

tool	j	run	real	user	sys	files
em	8	1	0m18.008s	2m12.733s	0m9.387s	31880
egencache	8	1	5m24.107s	0m0.003s	0m0.004s	31880
pk	8	1	0m48.226s	5m27.982s	1m8.484s	31880
em	16	1	0m10.115s	2m17.674s	0m11.647s	31880
egencache	16	1	4m36.731s	0m0.000s	0m0.007s	31880
pk	16	1	0m28.172s	6m0.818s	1m22.995s	31880
em	20	1	0m9.593s	2m27.314s	0m13.700s	31880
egencache	20	1	4m35.749s	0m0.000s	0m0.006s	31880
pk	20	1	0m23.707s	5m55.650s	1m33.241s	31880
em	24	1	0m9.229s	2m39.258s	0m16.244s	31880
egencache	24	1	4m56.389s	0m0.007s	0m0.000s	31880
pk	24	1	0m23.367s	5m54.775s	1m44.188s	31880

Here we see that the rust implementation are way faster and portage-repo parallel visit via jwalk has an edge.

dependency resolution

Only emerge and em have a resolver wired in and the search support.

RUNS=2 EM=target/release/em ./benchmarks/bench-em-vs-emerge.sh

Benchmark	em (mean ± σ)	emerge (mean ± σ)	speedup (em vs emerge)
firefox -p	0.917 s ± 0.082 s	3.675 s ± 0.000 s	4.01×
libreoffice -p	0.918 s ± 0.026 s	3.953 s ± 0.013 s	4.31×
multi (5 pkgs) -p	1.041 s ± 0.025 s	4.724 s ± 0.196 s	4.54×
gcc -s	0.154 s ± 0.011 s	5.175 s ± 0.006 s	33.63×

Since it is fun to watch, here an example of em dealing with some use changes compared with emerge.

The pubgrub solver wiring covers already plenty of the niceties of emerge, but I need to test it more.

Progress so far

To make updating simpler all the crates are now in the same portage-cli monorepo and most are already released, with few on hold waiting on having all the fixes I prepared for brush landing (help reviewing and polishing very welcome).

Crate	Version	Status	crates.io
gentoo-interner	0.3.1	Published	crates.io/crates/gentoo-interner
gentoo-core	0.5.1	Published	crates.io/crates/gentoo-core
gentoo-stages	0.5.1	Published	crates.io/crates/gentoo-stages
portage-atom	0.10.0	Published	crates.io/crates/portage-atom
portage-metadata	0.8.0	Published	crates.io/crates/portage-metadata
portage-atom-pubgrub	0.5.0	Published	crates.io/crates/portage-atom-pubgrub
portage-atom-resolvo	0.7.0	Published	crates.io/crates/portage-atom-resolvo
portage-vdb	0.1.0	Pending brush release	crates.io/crates/portage-vdb
portage-repo	0.1.0	Pending brush release	N/A
portage-distfiles	0.1.0	Pending brush release	N/A
portage-cli	0.1.0	~20% complete	N/A

Right now it is possible to enjoy a quite faster dependency resolution, cache regeneration and search. There is some essential support for building and merging packages, but it is far from being battle tested.

In the coming weeks I'll try to fill more gaps and make it more functional and hopefully blog more often.

Bringing up an AmpereOne system

Luca Barbato — Sat, 28 Feb 2026 17:16:52 +0000

I decided to buy something quite large since my workstations are aging and I wanted to build stuff quickly.

I decided to buy a AMPONED8-2T/BCM with a nice 128-cores CPU and a bit of RAM.

It took a bit for the people at https://www.mifcom.de/ to source all the components, but eventually I got it.

Initial Setup

The board comes with a very pretty BMC so all you need is to connect the management one (or any since they are bonded by default) and let the dhcp get an ip and then feed it to your browser.

Since I'm using Gentoo the boot media just worked, you may feed it directly from the Remote KVM

And just boot it from the browser

Then the process is the usual one

Partition and untar

Partition	Mount point	Filesystem	Recommended size	label
p1	/boot/efi	vfat	1 GiB	EF00
p2	/	btrfs	500+ GiB	8300
p3	/home	btrfs	500+ GiB	8302

mkfs.vfat -n EFI /dev/nvme0n1p1
mkdir /mnt/btrfs
mkfs.btrfs -L root --checksum xxhash /dev/nvme0n1p2
mount /dev/nvme0n1p2 /mnt/btrfs
btrfs subvolume create /mnt/btrfs/@
btrfs subvolume create /mnt/btrfs/@repos
btrfs subvolume create /mnt/btrfs/@snapshots
btrfs subvolume create /mnt/btrfs/@var_log
btrfs subvolume create /mnt/btrfs/@containers
umount /mnt/btrfs

mount -o subvol=@ /dev/nvme0n1p2 /mnt/gentoo
mkdir -p /mnt/gentoo/{.snapshots,var/{db/repos,log},var/lib/containers}
mount -o subvol=@snapshots /dev/nvme0n1p2 /mnt/gentoo/.snapshots
mount -o subvol=@repos     /dev/nvme0n1p2 /mnt/gentoo/var/db/repos
mount -o subvol=@var_logs  /dev/nvme0n1p2 /mnt/gentoo/var/log
mount -o subvol=@containers /dev/nvme0n1p2 /mnt/gentoo/var/lib/containers

cd /mnt/gentoo
wget {stage3}
tar -xpf {stage3}

Enter the stage

Usual chroot

# Mount special filesystems
mount --types proc /proc /mnt/gentoo/proc
mount --rbind /sys /mnt/gentoo/sys
mount --make-rslave /mnt/gentoo/sys
mount --rbind /dev /mnt/gentoo/dev
mount --make-rslave /mnt/gentoo/dev
mount --bind /run /mnt/gentoo/run
mount --make-slave /mnt/gentoo/run

# copy the nameservers already present
cp --dereference /etc/resolv.conf /mnt/gentoo/etc/

# Enter the chroot
env -i \
    HOME=/root \
    TERM="$TERM" \
    PS1="(chroot) $PS1" \
    chroot /mnt/gentoo /bin/bash --login

# Inside chroot now:
source /etc/profile
export PS1="(chroot) ${PS1}"

Initial bits to set up

emerge --sync
getuto
# Install your favourite editor, even from the binhost
emerge -G vim
# do your changes
vim /etc/portage/make.conf
# minimal and simple setup to to boot
emerge gentoo-sources grub dracut
eselect kernel set 1
cd /usr/src/linux
# the default config works well enough
zcat /proc/config.gz > .config
make olddefconfig
# add what you need for e.g. docker or lxd
make menuconfig
make -j 128 && make -j128 modules && make modules_install && make install
# set up your user
emerge supeadduser
superadduser
# set up ssh
emerge openssh metalog
rc-update add sshd
rc-update add metalog

All considered the whole process was quite uneventful and took literally minutes to then build additional toolchains and start doing some tests.

qlop -c | egrep 'llvm|rust'
app-eselect/eselect-rust: 2′38″ average for 1 merge
dev-lang/rust: 15′19″ average for 1 merge
dev-lang/rust-bin: 13′21″ average for 2 merges
dev-lang/rust-common: 42s average for 1 merge
dev-util/rustup: 1′42″ average for 1 merge
llvm-core/clang: 4′21″ average for 2 merges
llvm-core/clang-common: 12s average for 2 merges
llvm-core/clang-linker-config: 5′53″ average for 2 merges
llvm-core/clang-toolchain-symlinks: 5s average for 2 merges
llvm-core/llvm: 9′05″ average for 2 merges
llvm-core/llvm-common: 2′41″ average for 1 merge
llvm-core/llvm-toolchain-symlinks: 11s average for 2 merges
llvm-core/llvmgold: 7s average for 2 merges
llvm-runtimes/clang-rtlib-config: 5′54″ average for 2 merges
llvm-runtimes/clang-runtime: 6s average for 2 merges
llvm-runtimes/clang-stdlib-config: 5′56″ average for 2 merges
llvm-runtimes/clang-unwindlib-config: 5′58″ average for 2 merges
llvm-runtimes/compiler-rt: 26s average for 2 merges
llvm-runtimes/compiler-rt-sanitizers: 37s average for 2 merges
llvm-runtimes/openmp: 6′10″ average for 2 merges

cargo-c common questions

Luca Barbato — Mon, 02 Sep 2024 09:44:38 +0000

I wrote and maintain cargo-c a cargo ~~applet~~ custom subcommand that let you build a rust crate sporting a C-API as a proper C library and install it along with C headers and pkg-config files.

When I notice some rust software sporting a C-API that I'd consider packaging in Gentoo I tend to provide a patch to add the few metadata entries needed to have cargo-c do all the work, some other people politely ask if cargo-c is supported and sometimes it is an uphill battle usually because the project maintainer doesn't know the required effort is minimum or is not aware setting crate-type=cdylib is not enough.

I'm writing this to explain some of the problems cargo-c solves and hopefully give few pointers since the README containing all the documentation maybe grew to be fairly big.

In closing

I hope this article helps people convince maintainers of crates trying to replace a C library to adopt it since it will spare quite a bit of headaches to distributors and make much simpler to foster adoption of memory-safer alternatives.

Is cargo/rustc that slow?

Luca Barbato — Fri, 30 Aug 2024 15:12:40 +0000

As a side-discussion from the ongoing mess I read this about Waiting 15 minutes for a small program, e.g. like Yazi to compile is wild.

I tried and on my laptop took about 2 minutes to build in release mode, not too bad.

❯ cargo build
...
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 27.51s
❯ cargo clean
❯ cargo build --release
...
    Finished `release` profile [optimized] target(s) in 2m 01s

yazi isn't exactly a small program:

❯ cargo tree | grep -v yazi | wc -l
     685
❯ tokei
===============================================================================
 Language            Files        Lines         Code     Comments       Blanks
===============================================================================
 JSON                    1            1            1            0            0
 Lua                    34         1973         1639           31          303
 Markdown                2          207            0          149           58
 Nix                     4          270          235            6           29
 Shell                   3           56           41            6            9
 TOML                   18         1819         1484          128          207
 YAML                    1           33           29            1            3
-------------------------------------------------------------------------------
 Rust                  463        27288        22926          280         4082
 |- Markdown             6           56            0           51            5
 (Total)                          27344        22926          331         4087
===============================================================================
 Total                 526        31647        26355          601         4691
===============================================================================

Then I looked a bit further and I saw:

[profile.release]
codegen-units = 1
lto           = true
panic         = "abort"
strip         = true

Definitely not friendly if you want a fast release build

codegen-units = 1 may generate a bit more optimal code but then you can use only 1 core and if you have many...
lto = true tends to take lots of time for some optimality, but lto = "thin" exists and the tradeoff tends to be very good, for rav1e on x86_64 for a long while managed to produce even a better binary.

So what happens if I do those changes?

❯ cargo build --release
...
    Finished `release` profile [optimized] target(s) in 47.05s

I guess sometimes it is better to not stop at the first program to evaluate if a toolchain is fast or slow :)

P.S.

If you are on Linux, at least right now the quickest combination seems to be clang as linker with mold doing the actual work.
gcc + mold seems sensibly slower and clang + ld.bfd is curiously a tad slower than gcc + ld.bfd.
Setting

[target.{yourarch}]
linker = "clang"
rustflags = ["-C", "link-arg=-fuse-ld=mold"]

in ~/.cargo/config.toml may be optimal at least right now.

cross-stages experiments

Luca Barbato — Fri, 02 Aug 2024 09:15:40 +0000

I'm still playing with RISC-V and the bpi-f3.

Support status for BPI-F3 upstream

The upstreaming effort at least for the kernel is ongoing.

The bsp seems actively maintained with changes landing quite often in their fork of opensbi, u-boot and linux. Sadly being bsp and since it covers multiple boards they tend of lump lots of changes together so it can get annoying to follow what they are fixing or adding.

Given enough opensource developers are getting the board or similar hardware, I hope we'll have enough eyes and hands to clean up the code in a shape it can also be upstreamed to u-boot and opensbi.

My experiments

I wanted to see how different would feel a whole system built to leverage at least a bit RVV 1.0 through the compiler, sadly until this bug won't be addressed it would be hard to have a fully working system compiled with the autovectorizer on and I found it out the hard way.

The Gentoo default way to build stages and images via catalyst relies on qemu-user when no fast native system is available to avoid pitfalls of packages failing at cross-compilation. It is a bit slow but fairly reliable.

Since things should improve over time, I tried to leverage crossdev and see if:

[x] At least the stage1 packages could be cross-compiled and installed via crossdev (perl seems the only package misbehaving)
[x] Freshening a stage3 works. As seen with cross-boss it feasible, I wanted to see it can be made even more straightforward.
[x] Add packages and setup demons

All without using qemu-user so it can be made quickly, so far it mostly works.

On top of it I just cross-compiled the bsp packages and copied the approach they used to assemble the final image using genimage, trying to make it as simple as possible by using a single configuration file that does everything in a single invocation.

The crossdev-stages set of scripts should let anybody with a recent Gentoo with the dependencies listed to build their images in reasonable time.

Usage

I prepared 3 scripts:

chroot-stage.sh that make quite easy to fetch a stage3, unpack it and and optionally enter it using bubblewrap (thanks chewi for introducing me to it).

# If you already have Gentoo you can just fetch the stage
$ bash chroot-stage.sh setup stage3/ riscv64
# If you do not have Gentoo you can use the script to have a host chroot
$ bash chroot-stage.sh setup my-chroot
$ bash chroot-stage.sh enter my-chroot

cross-stage.sh that takes care of all the building, you can go from-scratch or start from a pre-existing stage3

# This will rebuild all the stage3 using the newer compiler and the CFLAGS you set in the script
$ bash cross-stage.sh update stage3/
# Install the bare minimum needed to have the bootloader working
$ bash cross-stage.sh install_boot stage3/
# Install additional packages you may find useful
$ bash cross-stage.sh install_more stage3/

make-image.sh that puts everything together and build the bsp packages.

# It will produce a gentoo-linux-k1_dev-sdcard.img.xz in the build-directory
$ bash make-image.sh /tmp/build-directory stage3/

So far it works for me you are welcome to try it, help improving it or just use the pre-made image.

Enjoy!

Bringing up BPI-F3 - Part 3

Luca Barbato — Tue, 04 Jun 2024 17:45:32 +0000

Initramfs

Initially I was hoping that it would not be needed, but since the SoC has a remote processor and the defconfig for it enables it, I guess it is simpler to use an initramfs.

Remoteproc firmware

As seen here the remoteproc needs a firmware bit and if you happen to forget about it you'd be welcomed by:

[    4.205609] remoteproc remoteproc0: rcpu_rproc is available
[    4.211421] remoteproc remoteproc0: Direct firmware load for esos.elf failed with error -2
[    4.214379] riscv-pmu-sbi: SBI PMU extension is available
[    4.219790] remoteproc remoteproc0: powering up rcpu_rproc
[    4.225306] riscv-pmu-sbi: 16 firmware and 18 hardware counters
[    4.230776] remoteproc remoteproc0: Direct firmware load for esos.elf failed with error -2
[    4.245106] remoteproc remoteproc0: request_firmware failed: -2
[    4.246235] es8326 2-0019: assuming static mclk
[    4.256170] enter spacemit_snd_sspa_pdev_probe
[    4.301833] usb 2-1: new high-speed USB device number 2 using xhci-hcd

If you like to use dracut all you need is to add to your /etc/dracut.conf.d/firmware.conf is:

install_items+=" /lib/firmware/esos.elf "

If you use Genkernel, set in /etc/genkernel.conf:

# Add firmware(s) to initramfs
FIRMWARE="yes"

# Specify directory to pull from
FIRMWARE_DIR="/lib/firmware"

# Specify a comma-separated list of firmware files or directories to include,
# relative to FIRMWARE_DIR.  If empty or unset, the full contents of 
# FIRMWARE_DIR will be included (if FIRMWARE option above is set to YES).
FIRMWARE_FILES="esos.elf"

as explained here.

Coming next

Now the remaining bits I'd like to have done are having a nicer u-boot configuration and hopefully wrap everything up so we can have a Gentoo image that can be simply flashed to the SD/eMMC/NVMe.

Bringing up BPI-F3 - Part 2.5

Luca Barbato — Fri, 24 May 2024 07:31:29 +0000

this is a sort of intermission

Getting perf to work up to a point

Apparently the opensbi-mediated access to the performance counter does not map so using the usual cycles and instructions event works in perf record. I got this board mainly to help with dav1d development efforts, so not having perf support would make harder to reason about performance.

The best workaround after a discussion in the forums, is to build the pmu-events to include custom ones and then rely on the overly precise cpu-specific events instead:

$ perf list | grep cycle
  bus-cycles                                         [Hardware event]
  cpu-cycles OR cycles                               [Hardware event]
  ref-cycles                                         [Hardware event]
  stalled-cycles-backend OR idle-cycles-backend      [Hardware event]
  stalled-cycles-frontend OR idle-cycles-frontend    [Hardware event]
  m_mode_cycle
       [M-mode cycles]
  rtu_flush_cycle
  s_mode_cycle
       [S-mode cycles]
  stalled_cycle_backend
       [Stalled cycles backend]
  stalled_cycle_frontend
       [Stalled cycles frontend]
  u_mode_cycle
       [U-mode cycles]
  vidu_total_cycle
  vidu_vec0_cycle
  vidu_vec1_cycle
...

$ perf list | grep inst
  branch-instructions OR branches                    [Hardware event]
  instructions                                       [Hardware event]
  br_inst
       [Branch instructions]
  cond_br_inst
       [Conditional branch instructions]
  indirect_br_inst
       [Indirect branch instructions]
  taken_cond_br_inst
       [Taken conditional branch instructions]
  uncond_br_inst
       [Unconditional branch instructions]
instruction:
  alu_inst
       [ALU (integer) instructions]
  amo_inst
       [AMO instructions]
  atomic_inst
       [Atomic instructions]
  bus_fence_inst
       [Bus FENCE instructions]
  csr_inst
       [CSR instructions]
  div_inst
       [Division instructions]
  ecall_inst
       [ECALL instructions]
  failed_sc_inst
       [Failed SC instructions]
  fence_inst
       [FENCE instructions]
  fp_div_inst
       [Floating-point division instructions]
  fp_inst
       [Floating-point instructions]
  fp_load_inst
       [Floating-point load instructions]
  fp_store_inst
       [Floating-point store instructions]
  load_inst
       [Load instructions]
  lr_inst
       [LR instructions]
  mult_inst
       [Multiplication instructions]
  sc_inst
       [SC instructions]
  store_inst
       [Store instructions]
  unaligned_load_inst
       [Unaligned load instructions]
  unaligned_store_inst
       [Unaligned store instructions]
  vector_div_inst
       [Vector division instructions]
  vector_inst
       [Vector instructions]
  vector_load_inst
       [Vector load instructions]
  vector_store_inst
       [Vector store instructions]
  id_inst_pipedown
       [ID instruction pipedowns]
  id_one_inst_pipedown
       [ID one instruction pipedowns]
  issued_inst
       [Issued instructions]
  rf_inst_pipedown
       [RF instruction pipedowns]
  rf_one_inst_pipedown
       [RF one instruction pipedowns]

Building perf

Perf way to deal with cpu-specific events is through some machinery called jevents.

It lives in tools/perf/pmu-events and you can manually trigger it with.

./jevents.py riscv arch pmu-events.c

And produce C code from a bunch of JSON and a CSV map file.

When I tried build the sources the first time I tried to cut it by setting most NO_{} make variables and left NO_JEVENTS=1, luckily I fixed it after noticing the different output in the forum.

## I assume you have here the custom linux sources
cd /usr/src/pi-linux/tools/perf
## being lazy I disabled about everything instead of installing dependencies, one time I disabled too much.
make -j 8 V=1 VF=1 HOSTCC=riscv64-unknown-linux-gnu-gcc HOSTLD=riscv64-unknown-linux-gnu-ld CC=riscv64-unknown-linux-gnu-gcc CXX=riscv64-unknown-linux-gnu-g++ AR=riscv64-unknown-linux-gnu-ar LD=riscv64-unknown-linux-gnu-ld NM=riscv64-unknown-linux-gnu-nm PKG_CONFIG=riscv64-unknown-linux-gnu-pkg-config prefix=/usr bindir_relative=bin tipdir=share/doc/perf-6.8 'EXTRA_CFLAGS=-O2 -pipe' 'EXTRA_LDFLAGS=-Wl,-O1 -Wl,--as-needed' ARCH=riscv BUILD_BPF_SKEL= BUILD_NONDISTRO=1 JDIR= CORESIGHT= GTK2= feature-gtk2-infobar= NO_AUXTRACE= NO_BACKTRACE= NO_DEMANGLE= NO_JEVENTS=0 NO_JVMTI=1 NO_LIBAUDIT=1 NO_LIBBABELTRACE=1 NO_LIBBIONIC=1 NO_LIBBPF=1 NO_LIBCAP=1 NO_LIBCRYPTO= NO_LIBDW_DWARF_UNWIND= NO_LIBELF= NO_LIBNUMA=1 NO_LIBPERL=1 NO_LIBPFM4=1 NO_LIBPYTHON=1 NO_LIBTRACEEVENT= NO_LIBUNWIND=1 NO_LIBZSTD=1 NO_SDT=1 NO_SLANG=1 NO_LZMA=1 NO_ZLIB= TCMALLOC= WERROR=0 LIBDIR=/usr/libexec/perf-core libdir=/usr/lib64 plugindir=/usr/lib64/perf/plugins -f Makefile.perf install

Now I have a perf with still cycles and instructions not working with perf record, I wonder if there is a way at opensbi or kernel level to aggregate events to make it work properly, but I never had to look into perf internals so probably I poke it way later if nobody address it otherwise, anyway

perf record --group -e u_mode_cycle,m_mode_cycle,s_mode_cycle

produces something close enough for cycles, well u_mode_cycle is enough.

While for instructions the situation is a bit more annoying

perf record --group -e alu_inst,amo_inst,atomic_inst,fp_div_inst,fp_inst,fp_load_inst,fp_store_inst,load_inst,lr_inst,mult_inst,sc_inst,store_inst,unaligned_load_inst,unaligned_store_inst

is close to count all the scalar instructions, but trying to add vector_div_inst,vector_inst,vector_load_inst,vector_store_inst somehow makes perf record stop collecting samples silently, adding just 3 more events works though, so I guess I can be happy with u_mode_cycle,alu_inst,atomic_inst,fp_inst,vector_inst at least.

Bringing up BPI-F3 - Part 2

Luca Barbato — Mon, 20 May 2024 19:38:42 +0000

This is part2, in part1 I shown how to get a Gentoo system on the nvme taking some shortcuts. Here are the notes from the second day with some improvements.

Setting up the eMMC

stintel already documented how to build uboot and install it, I'm summarizing it as well here.

Dependencies

We need dtc to compile the device-tree and mkimage and git if we want to clone the trees.

emerge dtc u-boot-tools dev-vcs/git

Bootloader

This board boot process relies on opensbi + u-boot

First build opensbi

git clone https://github.com/BPI-SINOVOIP/pi-opensbi -b v1.3-k1
cd pi-opensbi
make PLATFORM=generic menuconfig
make -j 8

As stintel already reported, the default configuration is wrong, so we have to make sure that the build/platform/generic/kconfig/.config has the support for K1x:

# CONFIG_PLATFORM_SPACEMIT_K1PRO is not set
CONFIG_PLATFORM_SPACEMIT_K1X=y

If everything goes well build/platform/generic/firmware/fw_dynamic.bin will exist.

Then build u-boot

export OPENSBI=../pi-opensbi/build/platform/generic/firmware/fw_dynamic.bin
git clone https://github.com/BPI-SINOVOIP/pi-u-boot -b v2022.10-k1
cd pi-u-boot
make k1_defconfig
make -j8

If everything goes well it will produce the following files

FSBL.bin  
bootinfo_emmc.bin  
bootinfo_sd.bin  
bootinfo_spinand.bin  
bootinfo_spinor.bin 
u-boot.bin

Partitions

The upstream instructions suggest to copy over the layout, so the uboot, bootfs, rootfs partitions stay the same, but now the eMMC fsbl and opensbi are to live in their dedicated /dev/mmcblk2boot0. So it is up to you to do what you prefer with them.
Surely you have to setup /dev/mmcblk2boot0:

echo 0 > /sys/block/mmcblk2boot0/force_ro
dd if=bootinfo_emmc.bin of=/dev/mmcblk2boot0
dd if=FSBL.bin of=/dev/mmcblk2boot0 bs=512 seek=1

As stintel tested, all that's need is that a partition labeled uboot exists and contains u-boot.bin and a bootfs partition that contains env_k1-x.txt. It is a good idea to have env and rootfs as well.

Kernel

Building the kernel is straightforward enough:

git clone https://github.com/BPI-SINOVOIP/pi-linux -b linux-6.1.15-k1
ln -s pi-linux/ linux
cd linux
zcat /proc/config.gz > .config
make oldconfig # (or menuconfig)
make -j 10 && make modules_install
mount /boot # make sure it picks the right partition
make install

Make sure to enable HWMON and HWMON_NVME so you'll have the thermal sensors available.

Edit boot/env_k1-x.txt accordingly and your new kernel is ready.

NOTE: The initial kernel has at least a known annoying bug and it is missing HWMON support for its thermal sensors.
If you use Rust, you'll notice immediately some strange issue with futex().

here a patch to address the bug backported to the 6.1.15 vendored kernel.

here my tiny patch to get something going regarding HWMON.

Coming next

Do not use at all an initrd (right now if you are following along you'd be using the initrd from the starting distro)
Other u-boot tweaks

Bringing up BPI-F3 - Part 1

Luca Barbato — Sun, 19 May 2024 15:05:09 +0000

I like a lot non-x86 architectures, I still enjoy writing software for PowerPC even nowadays and I'm looking forward to see how SVE will be once there is hardware in the right price range.
Today it is the turn of RISC-V since there is eventually a, hopefully, nice board sporting a cpu with the RISC-V Vector Extension 1.0 that is now part of the RISC-V.

Where to start

The official documentation is available here.

The board comes with an empty eMMC, so either you start with a SD, or you need to upload a valid image using dfu.

Sadly the usb-c does not multiplex also the serial, so you'll need to connect the usual 3 pins with a 3.3V usbserial.

ERROR:   CMD8
ERROR:   sd f! l:76
bm:0
ERROR:   emmc: invalid bootinfo magic code:0x0
ERROR:   invalid bootinfo image.
ERROR:   entering download mode.
ROM: usb download handler
usb2d_initialize : enter
Force usb FS mode!
Controller Run
usb rst int
SETUP: 0x0 0x5 0x1
SETUP: 0x80 0x6 0x100
SETUP: 0x80 0x6 0x100
SETUP: 0x80 0x6 0x302
SETUP: 0x80 0x6 0x302
SETUP: 0x80 0x6 0x301
SETUP: 0x80 0x6 0x301
SETUP: 0x80 0x6 0x30a
SETUP: 0x80 0x6 0x30a
SETUP: 0x80 0x6 0x200
SETUP: 0x80 0x6 0x200
SETUP: 0x80 0x6 0x300

Their images are Debian derivatives, I prefer Gentoo and since we have stage3 for rv64_lp64d-openrc, I guess I can give it a try.

Vendor-sources for kernel and bootloaders are available and I can piggy back over that image if I stumble over opensbi or u-boot or I run out of time sorting out the patches for linux-6.1.15

Prerequisites

wezterm or screen to see what's going on
u-boot-tools are needed since the kernel image will would come in a FIT image.
The armbian tree or any of the pre-made builds provided.
A recent stage3

Lazy Setup

The base images share this layout:

Number  Start (sector)    End (sector)  Size       Code  Name
   1             256             767   256.0 KiB   8300  fsbl
   2             768             895   64.0 KiB    8300  env
   3            2048            4095   1024.0 KiB  8300  opensbi
   4            4096            8191   2.0 MiB     8300  uboot
   5            8192          532479   256.0 MiB   8300  bootfs
   6          532480              <>   <> GiB     8300  rootfs

With the rootfs taking the space it needs.

The easiest way is to copy the first 5 partitions to the eMMC

# dd if=/dev/mmcblk0 of=/dev/mmcblk2 bs=1M count=259

And then recreate the rootfs partition.

[!note] the initramfs does not support btrfs, nor the u-boot configuration. Until kernel and initramfs are replaced it is safer to stick to ext4 (I made this mistake).

Then the usual manual unpack of a stage3 and chroot described in Gentoo Handbook works.

Pitfalls known so far

Make sure to enable the serial ports in /etc/inittab

s0:12345:respawn:/sbin/agetty -L 115200 ttyS0 vt100
s1:12345:respawn:/sbin/agetty -L 115200 ttyS1 vt100

The default u-boot command script is incomplete, if you want to use the nvme, you have to enter the u-boot console (press s)

=> nvme scan
=> run nor_boot

Coming next

I hadn't tried yet to:

update u-boot and change a bit its configuration
build a new kernel
put everything together to have btrfs on nvme

DEV Community: Luca Barbato

winnow-args 0.5.0

What changed

Errors and rules

Values and defaults

Subcommands

Help

Deprecation

Completion and pages

Coming next

winnow-args: yet another args parser

Why another one

Speed on the cli?

How can a cli be annoyingly irregular?

winnow-args

mini-mise

Help, from the doc comments

Palettes and themes

Extended error reporting

Completion that asks the program

Exotic syntaxes

Under the hood

Key features

Performance

Implemented features

In closing

pseudoroot, fakeroost, hakoniwa... How to deal with unpriviledge packaging?

Build systems and root privileges

To root or not to root

Faking root

LD_PRELOAD

ptrace

Linux namespaces

So far

portage-cli

Some numbers

metadata regen

dependency resolution

Progress so far

Bringing up an AmpereOne system

Initial Setup

Partition and untar

Enter the stage

Initial bits to set up

cargo-c common questions

Top 6 questions, and their answers

Why this exists, why cargo isn't doing all of this on its own?

I prefer doing it on my own, why should I use cargo-c

I'm fine with just giving a static library, the user can copy it as they want

Does cargo-c require lots to set up?

How secure is cargo-c?

Since cargo-c is a cargo extension, why not move it in cargo?

In closing

Is cargo/rustc that slow?

P.S.

cross-stages experiments

Support status for BPI-F3 upstream

My experiments

Usage

Bringing up BPI-F3 - Part 3

Initramfs

Remoteproc firmware

Coming next

Bringing up BPI-F3 - Part 2.5

Getting perf to work up to a point

Building perf

Bringing up BPI-F3 - Part 2

Setting up the eMMC

Dependencies

Bootloader

Partitions

Kernel

Coming next

Bringing up BPI-F3 - Part 1

Where to start

Prerequisites

Lazy Setup

Pitfalls known so far

Coming next