On Fri, May 17, 2019 at 10:43 AM Stephen Boyd <sboyd@xxxxxxxxxx> wrote: > > Quoting Brendan Higgins (2019-05-14 15:16:56) > > A number of test features need to do pretty complicated string printing > > where it may not be possible to rely on a single preallocated string > > with parameters. > > > > So provide a library for constructing the string as you go similar to > > C++'s std::string. > > > > Signed-off-by: Brendan Higgins <brendanhiggins@xxxxxxxxxx> > > Reviewed-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > > Reviewed-by: Logan Gunthorpe <logang@xxxxxxxxxxxx> > > Is there any reason why we can't use the seqfile API for this? These > both share a similar goal, formatting strings into a buffer to be read > later. Maybe some new APIs would be needed to extract the buffer > differently, but I hope we could share the code. I can see why you are asking. It seems as though they are trying to do *similar* things, and it seems possible that we might be able to extract some common functionality out of seq_file that could replace this; however, it looks like it would be require a significant refactoring of seq_file to separate out the file system specific bits from the more general stringbuilder functionality. In my opinion, a refactoring like this makes no sense in this patchset; it probably belongs in its own patchset (preferably as a follow on). I also am not sure if the FS people would appreciate indirection that serves them no benefit, but I can ask if you like. > If it can't be used, can you please add the reasoning to the commit text > here? Will do. Thanks!
