gnop(8): Nopify configuration as a kernel dump device

[cem]

Summary

As a dummy / no-op dump device, to facilitate dumpon(8) testing.

Test Plan

This was useful for me playing around with dumpon(8) enhancements in the works
(i.e., "md0.nop").

It might be more valid to instead add fake dump support in the md device layer,
but there it is sort of less obvious that the support should be quite as
fake/nop as this is. This seems pretty straightforward, and I think we can
just trust users not to 'dumpon foo.nop' instead of 'dumpon foo' if they want
real kernel dumps.

[asomers]

Since this is just for development, should it be guarded by #ifdef INVARIANTS?

[cem]

In D19991#429682, @asomers wrote:

Since this is just for development, should it be guarded by #ifdef INVARIANTS?

Hm, I don’t understand why we would do that. It wouldn’t interfere with my current work, but we don’t disable kernel dumps on !INVARIANTS otherwise.

[asomers]

In D19991#429683, @cem wrote:

In D19991#429682, @asomers wrote:

Since this is just for development, should it be guarded by #ifdef INVARIANTS?

Hm, I don’t understand why we would do that. It wouldn’t interfere with my current work, but we don’t disable kernel dumps on !INVARIANTS otherwise.

I'm just thinking in terms of reducing binary size on normal builds. This doesn't have any uses on a normal system, does it?

[markj]

I don't have any objection to it, but why not use a real dump device for testing?

[cem]

In D19991#429684, @asomers wrote:

I'm just thinking in terms of reducing binary size on normal builds. This doesn't have any uses on a normal system, does it?

Well, ok. I suspect the impact on binary size is negligible. One could probably also just remove geom_nop.ko entirely on normal systems.

In D19991#429690, @markj wrote:

I don't have any objection to it, but why not use a real dump device for testing?

My test machine didn't have any free real devices so I had to synthesize some devices out of midair. mdconfig / gnop create is just the most straightforward way to do that.

[asomers]

In D19991#429726, @cem wrote:

In D19991#429684, @asomers wrote:

I'm just thinking in terms of reducing binary size on normal builds. This doesn't have any uses on a normal system, does it?

Well, ok. I suspect the impact on binary size is negligible. One could probably also just remove geom_nop.ko entirely on normal systems.

Good point. No point conditionalizing a portion of geom_nop then.

In D19991#429690, @markj wrote:

I don't have any objection to it, but why not use a real dump device for testing?

My test machine didn't have any free real devices so I had to synthesize some devices out of midair. mdconfig / gnop create is just the most straightforward way to do that.

@markj being able to create a geom device from an md or a file is super-useful for ATF tests.

[markj]

In D19991#429690, @markj wrote:

I don't have any objection to it, but why not use a real dump device for testing?

My test machine didn't have any free real devices so I had to synthesize some devices out of midair. mdconfig / gnop create is just the most straightforward way to do that.

@markj being able to create a geom device from an md or a file is super-useful for ATF tests.

Sure, I've done it before. Any tests for kernel dump code aren't going to provide much coverage unless they actually trigger kernel dumps, though, so at some point you're going to need a real dump device anyway.

sys/geom/nop/g_nop.c

130 ↗

(On Diff #56437)

Redundant parens.

[cem]

sys/geom/nop/g_nop.c

130 ↗

(On Diff #56437)

Will fix before commit. Inherited from, uh, I think I copied this from geom_disk.c.