On Fri, Jul 11, 2025 at 10:58:56AM -0700, Linus Torvalds wrote: > 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.
I actually wanted to go one step further with this (that's why I took readpos out of seq_buf in d0ed46b60396). If you look at the guts of vsprintf.c, it'd be much improved by using seq_buf internally instead of passing around buf and end. Once we've done that, maybe we can strip these annoying %pXYZ out of vsprintf.c and use seq_buf routines like it's a StringBuilder (or whatever other language/library convention you prefer). Anyway, I ran out of time to work on it, but I still think it's worthwhile. And then there'd be a lot more commonality between regular printing and trace printing, which would be nice.
