

Improving kernel string handling - vezzy-fnord
https://lwn.net/Articles/643376/

======
userbinator
I wonder if many of those string copies could be removed completely with a
change in code structure, and the associated use of various fixed-length-
buffers; an OS kernel doesn't seem to me like a piece of software where string
manipulation is a significant part of its job (besides pathname handling.)

------
rwmj
If we're going to put large amounts of complexity into the kernel, then why
not use a pool allocator to manage string allocations? Pool allocators are
low-level enough that they you can understand what's happening when they go
wrong (unlike complex GCs), but make string handling code very simple.

Example code using a pool allocator I wrote about 15 years ago:
[http://git.annexia.org/?p=rws.git;a=blob;f=process_rq.c;h=a0...](http://git.annexia.org/?p=rws.git;a=blob;f=process_rq.c;h=a04ae91fe7fdbb99d137f83c497f16879b591ade;hb=HEAD#l200)

~~~
TorKlingberg
Interesting, but how are the strings free'd?

~~~
rwmj
When the pool is freed, all strings in it get freed. Generally you arrange
pools to be per-"request" (in a web server), but it might be per-syscall in a
kernel. At the end of the syscall, all strings get freed in one go.

Pools can also have parent/child relations, so when a parent pool is freed,
all child pools are freed.

------
commentnull
This is the kind of stuff you want running in a service out side of a micro
kernel, but as we are stuck with systemd/gnu/linux systems, this is what we
have...

~~~
agumonkey
I could further into the rant, I'm ...stunned by parsing logic crippled as
type specific functions.

Why does `strscpy_truncate(dst,src,count)` exist at all ? it seem like a
generic buffer/array `take(dst,src,count)`. And how problematic would be to
use a compiled regex to parse "major:minor", or proper logic by seeking for
':' and read before after that point.

~~~
to3m
The strcpy-type functions stop after they read a '\x0'. They are not like
memcpy!

