On Thu, 9 Aug 2018, Kyle Evans wrote:
On Thu, Aug 9, 2018 at 6:22 PM, Bruce Evans <b...@optusnet.com.au> wrote:
...
The only obvious bug in (a later version of) the output is a missing newline
for the tag.
My dmesg output on amd64:
X ---<<BOOT>>------<<BOOT>>---Test of early printf to msgbuf
X GDB: debug ports: sio
X KDB: current port: sio
X KDB: debugger backends: ddb gdb
X KDB: current backend: ddb
X Copyright (c) 1992-2018 The FreeBSD Project.
X ...
In -current, all of the lines before the copyright except the tag are broken
by printf() of them to an unmapped msgbuf. (The above output is without -v.
Many more lines are lost with -v.) In my version, msgbufinit() is called
earlier with a small message buffer to hold the early output.
I've not seen a compelling reason to switch this to printf() rather
than direct addition to the msgbuf after it's initialized, but I'll
humor you on this one because I don't really care either way and
you've been at this a lot longer than I have.
Thanks.
When you say you call msgbufinit() earlier-- before the static
environment is even setup, or at least after that?
The above is with a simplified version that first calls msgbufinit()
after the static env is set up. In other working versions, msgbufinit()
is called long before the static env is set up. In a commented out
version, a small MI msgbuf is statically initalized so that some msgbuf
is always mapped, but msgbufmapped still starts as 0 and msgbufinit()
must still be called to synchronize. Some synchronization is needed
since the msgbuf uses broken mutex locking and mutexes use curthread and
curthread is not initialized early. The simplified versions delay the
msgbufinit() calls until mutexes are initialized enough, and this
accidentally moves them after other initializations.
So the tunable is unavailable in the best version :-(. The small initial
msgbuf could even start with the statically initialized buffer containing
the tag, and must if it is to be ready to go without a synchronization call.
I haven't really noticed the need for this feature. I edit
/var/log/messages a lot and need to find the start of the data for
each boot, and just grep for kern.bootfile. But this depends on the
message buffer being clobbered by reboot, so that syslogd always adds
the kern.bootfile message before the data for the new boot. When the
data spans multiple boots, the kern.bootfile message is very misplaced
timestamps are wrong for the old data, and ...
Output across reboots also works right except for the missing newline:
X ---<<BOOT>>------<<BOOT>>---Test of early printf to msgbuf
....
X All buffers synced.
X ---<<BOOT>>------<<BOOT>>---Test of early printf to msgbuf
... actually, the output across reboots doesn't work write (unless you
modified dmesg and syslogd to use the tag to drop duplicates). dmesg
show the old boot messages by default, but syslogd shouldn't log them
again by default.
Right- I tried to maintain the form of the original patch and also
overlooked this. My revised patch [1] prints the boot tag only upon
first init of the message buffer, swaps it over to printf, and adds a
newline to whatever's been chosen as the boot tag.
[1] https://people.freebsd.org/~kevans/bde-boottag.diff
I won't have much time to check it for a few weeks.
Bruce
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
