On Fri, 11 Jul 2025 at 10:45, David Laight <david.laight.li...@gmail.com> wrote:
>
> What does that actually look like behind all the #defines and generics?
> It it continually doing malloc/free it is pretty much inappropriate
> for a lot of system/kernel code.
Honestly, the kernel approximately *never* has "string handling" in
the traditional sense.
But we do have "buffers with text". The difference typically exactly
being that allocation has to happen separately from any text
operation.
It's why I already suggested people look at our various existing
buffer abstractions: we have several, although they tend to often be
somewhat specialized.
So, for example, we have things like "struct qstr" for path
components: it's specialized not only in having an associated hash
value for the string, but because it's a "initialize once" kind of
buffer that gets initialized at creation time, and the string contents
are constant (it literally contains a "const char *" in addition to
the length/hash).
That kind of "string buffer" obviously isn't useful for things like
the printf family, but we do have others. Like "struct seq_buf", which
already has "seq_buf_printf()" helpers.
That's the one you probably should use for most kernel "print to
buffer", but it has very few users despite not being complicated to
use:
struct seq_buf s;
seq_buf_init(&s, buf, szie);
and you're off to the races, and can do things like
seq_buf_printf(&s, ....);
without ever having to worry about overflows etc.
So we already do *have* good interfaces. But they aren't the
traditional ones that everybody knows about.
Linus
