On Wed, Jul 12, 2023 at 03:38:44PM -0700, Kees Cook wrote: > Heh, yeah, I've been trying to aim people at using seq_buf instead of > a long series of snprintf/strlcat/etc calls. Where can I look at how > you wired this up to seq_buf/printbuf? I had trouble finding it when I > looked before. I'd really like to find a way to do it without leaving > around foot-guns for future callers of string_get_size(). :) > > I found the printbuf series: > https://lore.kernel.org/lkml/20220808024128.3219082-1-willy@xxxxxxxxxxxxx/ > It seems there are some nice improvements in there. It'd be really nice > if seq_buf could just grow those changes. Adding a static version of > seq_buf_init to be used like you have PRINTBUF_EXTERN would be nice > (or even a statically sized initializer). And much of the conversions > is just changing types and functions. If we can leave all that alone, > things become MUCH easier to review, etc, etc. I'd *love* to see an > incremental improvement for seq_buf, especially the heap-allocation > part. Well, I raised that with Steve way back when I was starting on the conversions of existing code, and I couldn't get any communication out him regarding making those changes to seq_buf. So, I'd _love_ to resurrect that patch series and get it in after the bcachefs merger, but don't expect me to go back and redo everything :) the amount of code in existing seq_buf users is fairly small compared to bcachef's printbuf usage, and what that patch series does in the rest of the kernel anyways. I'd rather save that energy for ditching the seq_file interface and making that just use a printbuf - clean up that bit of API fragmentation.
