On Mon, 2023-05-01 at 23:17 -0400, Kent Overstreet wrote: > On Mon, May 01, 2023 at 10:22:18PM -0400, James Bottomley wrote: > > It is not used just for debug. It's used all over the kernel for > > printing out device sizes. The output mostly goes to the kernel > > print buffer, so it's anyone's guess as to what, if any, tools are > > parsing it, but the concern about breaking log parsers seems to be > > a valid one. > > Ok, there is sd_print_capacity() - but who in their right mind would > be trying to scrape device sizes, in human readable units, If you bother to google "kernel log parser", you'll discover it's quite an active area which supports a load of company business models. > from log messages when it's available in sysfs/procfs (actually, is > it in sysfs? if not, that's an oversight) in more reasonable units? It's not in sysfs, no. As aren't a lot of things, which is why log parsing for system monitoring is big business. > Correct me if I'm wrong, but I've yet to hear about kernel log > messages being consider a stable interface, and this seems a bit out > there. It might not be listed as stable, but when it's known there's a large ecosystem out there consuming it we shouldn't break it just because you feel like it. You should have a good reason and the break should be unavoidable. I wanted my output in a particular form so I thought I'd change everyone else's output as well isn't a good reason and it only costs a couple of lines to avoid. > But, you did write the code :) > > > > If someone raises a specific objection we'll do something > > > different, otherwise I think standardizing on what userspace > > > tooling already parses is a good idea. > > > > If you want to omit the space, why not simply add your own > > variant? A string_get_size_nospace() which would use most of the > > body of this one as a helper function but give its own snprintf > > format string at the end. It's only a couple of lines longer as a > > patch and has the bonus that it definitely wouldn't break anything > > by altering an existing output. > > I'm happy to do that - I just wanted to post this version first to > see if we can avoid the fragmentation and do a bit of standardizing > with how everything else seems to do that. What fragmentation? To do this properly you move the whole of the current function to a helper which takes a format sting, say with a double underscore prefix, then the existing function and what you want become one line additions calling the helper with their specific format string. There's no fragmentation of the base function at all. James
