On Tue 2018-12-04 06:10:40, Tetsuo Handa wrote: > On 2018/12/04 0:06, Petr Mladek wrote: > >> If we modify print_time(), I think that the leading spaces inserted by > >> "%5lu" > >> makes little sense, for "%5lu" is too small for systems with uptime >= > >> 1.16 days > >> and parsers after all cannot assume fixed length for the timestamp field. > >> Then, > >> we could change from "%5lu.%06lu" to "%lu.%06lu" so that parsers (like > >> /bin/awk) > >> can get prefix part using white spaces as a delimiter. > > > > My primary concern was a human readability. The different header columns > > are separated by brackets and the message itself is separated by the space. > > PID_MAX_LIMIT is 4194304, which can take up to 10 bytes if [T%u] is used.
4194304 is the worst case. I would use the same approach as with the timestamp seconds. It uses 5 characters as the minimum. But it might eventully get bigger. IMHO, [T%5u] looks like a reasonable default. > But unless a race occurs, each series of printk() lines are printed with > same width. It is not about series of printk() lines. It is about readability of the entire log. > My concern is how to minimize number of characters written to > consoles, for writing to consoles are slow, and userspace usually uses > /dev/kmsg rather than netconsole as a source. For normal users who do not > need to directly parse console/netconsole output, saving spaces in the header > fields will be OK. The number of characters is important. But we do not need to get to the extreme. Readability by humans is important. > > /dev/kmsg uses key=value notation. It does not need any version. The > > version filed was intended for crashdump. It would make the life > > easier for its maintainers. > > If the version field is for crashdump rather than for netconsole, we can > get it from some vmcoreinfo variable rather than appending to every record. Exactly. And I asked you to add back VMCOREINFO_OFFSET(printk_log, from_id). Best Regards, Petr
