dmesg: Do not skip the first line anymore that was missing sincecommit "Make msgbuf_peekbytes() not return leading zeroes".

[olivier]

Summary

Sponsored by: Netflix

[olivier]

Before commit 81dc00331d1 "Make msgbuf_peekbytes() not return leading zeroes.", the dmesg just after the reboot is this output:

# dmesg | head -4
---<<BOOT>>---
Copyright (c) 1992-2022 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.

And after it is in this form:

# dmesg | head -4
Copyright (c) 1992-2021 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.'

The first line "--<<BOOT>>--- is now missing.
So, it seems that the "always remove the first line from dmesg" isn't needed anymore.

[mav]

sbin/dmesg/dmesg.c

186

There should be no leading zeroes now -- that was the actual reason for 81dc00331d1. I haven't touched this just for some transition period, but I don't think we support running newer world with older kernel where this would be needed.

[emaste]

sbin/dmesg/dmesg.c

186

Right, we make no claims about being able to run a new world on old kernel. There are some examples of special cases with a workaround to support upgrades (e.g. w/ ino64), but those have generally been only what's required for the upgrade to work, not to support ongoing use in that condition.

@mav you're suggesting just removing this block as well?

[emaste]

I'm fine with either removing the (!all) block first and potentially following up with (*p == '\0') in another change (i.e., this review) or removing both now.

[mav]

sbin/dmesg/dmesg.c

186

Yes, zeroes removal is not needed any more here and and in few places in kernel, calling msgbuf_peekbytes().

The only problem I've missed in my commit and noticed just now is that without those leading zeroes this code can't differentiate case of buffer wrap, and without that it can't say when the first line may be trucated, and for the truncated line it does not have a priority value, so can't say whether buffer starts from a kernel message or truncated "syslog record". Ideas are welcome.