Netconsole implementation for FreeBSD

[kibab]

Summary

Implement very basic read-only console that sends all kernel messages via UDP to the specified host.
As soon as there is a routable network, all messages since the system boot (but currently max 16 KB, limit subject to change) are sent to the specified host (set via kenv variable netconsole.host) port 6666 (not changeable. Why? Dunno. Easy to fix!).

This is somewhat similar to Linux Netconsole module. It can help in situations when the system panics shortly before starting SSH, or if there is no SSH at all, ot the system is too slow to pipe kernel messages via syslog / SSH at sufficient rate.

Test Plan

• Compile and install module
• kenv set netconsole.host=XXX.XXX.XXX.XXX (IPv4 address only, no hostnames)
• kldload netcons

On the target host:
$ nc -ukl 6666

Enjoy.

[benno]

Have you looked at markj's netdump branch? Would his lower-level UDP send routines be a better transport for the console messages?

sys/dev/netcons/netcons.c

56

Not sure that we want this one in head. 🙃

[markj]

In D13064#299426, @benno wrote:

Have you looked at markj's netdump branch? Would his lower-level UDP send routines be a better transport for the console messages?

That code is specifically designed to run after a panic, while this is not. Ideally netcons would be usable in either context, but I wouldn't consider that to be a gating feature.

[cem]

sys/dev/netcons/netcons.c

66

Consider more verbose names for globally visible symbols. Grepping for 's' is going to highlight a lot of false positives.

Also, this can and probably should be static as well.

73

style nits:

Use (void), not (). The latter is a declaration with unspecified parameters; the former is zero parameters.

Opening curly braces ("{") go on their own line (style(9)).

75

style(9) nit: Blank line between variable declarations and code

80

style(9) nit: return (err);

[cem]

Haven't done a thorough review, but will take another look when some of the outstanding issues are cleaned up.

sys/dev/netcons/netcons.c

172

These values should be an enum

322

The sleep thread needs to signal back that it is done using the resources we destroy below before we continue.

328

style nit: compare pointers with NULL rather than treating them as boolean values

[kibab]

In D13064#299460, @markj wrote:

In D13064#299426, @benno wrote:

Have you looked at markj's netdump branch? Would his lower-level UDP send routines be a better transport for the console messages?

That code is specifically designed to run after a panic, while this is not. Ideally netcons would be usable in either context, but I wouldn't consider that to be a gating feature.

Actually I need precisely that! Running UDP send after panic would help to see a panic message. What is the purpose of netdump branch, what are you developing there?

[kibab]

In D13064#303809, @cem wrote:

Haven't done a thorough review, but will take another look when some of the outstanding issues are cleaned up.

Thank you! I will address your comments and upload a new revision.

[markj]

In D13064#307542, @kibab wrote:

In D13064#299460, @markj wrote:

In D13064#299426, @benno wrote:

Have you looked at markj's netdump branch? Would his lower-level UDP send routines be a better transport for the console messages?

That code is specifically designed to run after a panic, while this is not. Ideally netcons would be usable in either context, but I wouldn't consider that to be a gating feature.

Actually I need precisely that! Running UDP send after panic would help to see a panic message. What is the purpose of netdump branch, what are you developing there?

The aim is to make it possible to transmit kernel dumps after a panic. See the netdump.4 and dumpon.8 man pages in that branch. I've been meaning to get it into FreeBSD for a long time and would rather not hold it up to add new features now, as I'm basically ready to get it reviewed and merged, but I'd be happy to work on refactoring it for use by other subsystems afterwards.

[kibab]

In D13064#307569, @markj wrote:

In D13064#307542, @kibab wrote:

In D13064#299460, @markj wrote:

In D13064#299426, @benno wrote:

Have you looked at markj's netdump branch? Would his lower-level UDP send routines be a better transport for the console messages?

That code is specifically designed to run after a panic, while this is not. Ideally netcons would be usable in either context, but I wouldn't consider that to be a gating feature.

Actually I need precisely that! Running UDP send after panic would help to see a panic message. What is the purpose of netdump branch, what are you developing there?

The aim is to make it possible to transmit kernel dumps after a panic. See the netdump.4 and dumpon.8 man pages in that branch. I've been meaning to get it into FreeBSD for a long time and would rather not hold it up to add new features now, as I'm basically ready to get it reviewed and merged, but I'd be happy to work on refactoring it for use by other subsystems afterwards.

OK, that's good to know. I've talked to Sam Gwydir at AsiaBSDCon and seems that netdump is really a good fit for netcons. If you can get it reviewed and committed as-is, we can try to get a student to work on generalizing this / using for netcons during GSoC!

[markj]

In D13064#307684, @kibab wrote:

OK, that's good to know. I've talked to Sam Gwydir at AsiaBSDCon and seems that netdump is really a good fit for netcons. If you can get it reviewed and committed as-is, we can try to get a student to work on generalizing this / using for netcons during GSoC!

JFYI, the core client code was committed in r333283 and I don't have any near-term plans to change it significantly. I'm happy to review changes or discuss approaches to refactoring that code into something usable by netcons.

[brd]

Ping? This idea is pretty useful for debugging, maybe it can be finished up and brought into the tree?