Re: My experiences with Rust
- Reply: Anthony Pankov : "Re: My experiences with Rust"
- In reply to: Poul-Henning Kamp: "Re: My experiences with Rust"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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>