Re: My experiences with Rust

From: Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp>
Date: Fri, 22 Aug 2025 22:32:25 UTC
On Fri, 22 Aug 2025 21:33:55 +0000
"Poul-Henning Kamp" <phk@phk.freebsd.dk> wrote:

> --------
> Vadim Goncharov writes:
> 
> 
> > And nobody needs to open "format" *directly* in text editor 
> 
> Yes, people actually do, and the ability to do things like that is
> why UNIX has beaten out all the crappy systems where you needed 
> 19 different programs to see 15 different binary data formats.
> 
> -- 
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe    
> Never attribute to malice what can adequately be explained by incompetence.

It would depends on what's the data is.
For output-only data from kernel TO BE LOGGED, text-only format would be
strictly wanted to read/process using oldies-but-goodies tools like
less, grep, awk, sed and any other thing to handle texts.
Structured text format would be preferred but not mandatory here.

OTOH, data for configurations that is used to reading current state and
setting to-be-changed configs should be strictly in easy-to validate
text formats.

And any others that is updated in kernel quite often (i.e., updated
in every ticks or more) should be in binary C data format NOT to add
extra workloads for kernel. And anything allowed to be read/written
from userland tools should be strictly defined and centralized into
specific kernel memory area (preferrably in single segment dedicated
for the purpose) that is sanely and effectively protected by physical
MMU access modes / priviledges and should always treated as volatile
data, as kernel is free to update in any time even on anything in
userland is just reading the specific part. And should NOT be allowed
to directly write from userland programs.
(If sane data is wanted, specific KPI shoule be defined here.)

Regards.

-- 
Tomoaki AOKI    <junchoon@dec.sakura.ne.jp>