On Wed, 2023-05-03 at 08:50 +1000, Dave Chinner wrote: > On Tue, May 02, 2023 at 07:42:59AM -0400, James Bottomley wrote: > > 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. > > That doesn't mean log messages are unchangable ABI. Indeed, we had > the whole "printk_index_emit()" addition recently to create > an external index of printk message formats for such applications to > use. [*] I didn't say they were. > > > > 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. > > And that big business is why printk_index_emit() exists to allow > them to easily determine how log messages change format and come and > go across different kernel versions. > > > > 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. > > But we've solved this problem already, yes? Well, yes; since it's a simple bit of extra thought and a couple of lines addition not to afflict everyone with the change, that's the simplest course. It also gets us out of arguing about whether the space reads better and is SI consistent. > If the userspace applications are not using the kernel printk format > index to detect such changes between kernel version, then they > should be. This makes trivial issues like whether we have a space or > not between units is completely irrelevant because the entry in the > printk format index for the log output we emit will match whatever > is output by the kernel.... Just because we have better tools to fix a problem when it happens doesn't mean we should actively cause the problem when its easily avoidable. In the same way we shouldn't drive less carefully just because cars are built safer today. James
