This is the current intended semantic of 'run-time' events; everything logged after the completion of rc scripts (or to be precise, when init(8) transitions to multi-user) but before shutdown has begun. For example, loading a kmod on the command line will create an event in the run-time event buffer.

We consider execution of rc scripts to be part of 'boot-time', but the choice is somewhat arbitrary.

I'm marking this discussion as resolved for now. The semantic seems to be good enough.

Good idea. I'm moving this part to the description section and adding that include statement.

I think that it is alright to add some more details here. We didn't mention the event annotations earlier. I thought about making it a bit concise for a moment but I didn't find a better way to express it.

I'd not go into details of panics here. This should be covered in a separate document explaining what a kernel panic is and how it can be occur.

I agree that "upon initialization" may sound like a user-initiated action. I cannot think of a better way to write this sentence, though.

Please let me know if you have anything on your mind.

Makes sense. Also, many other many other manpages do that, eg. vte(4).

Thanks. I'll include that in a patch shortly.

I cannot find that anymore. I think I was confusing the ${procname}: name format used by boottrace somewhere internally I suppose and the format of kern.boottrace.log.

That's a good question. I'll ask @mhorne about it.

Oh I get it now. I'll add this bit of information to the manual.

Done!

Good question, I'll look into that.

It is the executable name. See getprogname(3) for details.

It is always the executable name, as neither setprogname() nor setproctitle() change the process's name from the kernel's POV.

Ach, I didn't know about that. Thanks!

I'll ask @mhorne about it.

It logs everything that has been recorded in the boot-time and run-time event tables (whether the kernel or userspace generated the event). It doesn't include shutdown events, because this sysctl is not expected to be invoked at any point during shutdown. There is the kern.boottrace.shutdown_trace option to have those events printed before the system performs its final shutdown action(s).

@debdrup raised the point in D31929 that we should not exceed 80 characters. I was able to squish the output there to make it fit, but not sure what should be done here...

There's a lot of empty space that can be elided, which should make it possible to fit within the 80 character limit.

I assume that this is the exact output format of that sysctl. I'd prefer to stay as close to the real output as possible.

However, if @mhorne managed to make the output of this sysctl narrower, then we should definitely update this example to reflect those changes.

It was a part of an old template. I removed it.

good idea

I removed it. We should have a dedicated manual page for comparison of tracing facilities. Also, we need a tslog manual page.