bhyve/snapshot: switch to nvlist for snapshot requests

[rew]

Summary

Switch to using an nvlist with nvlist_send()/nvlist_recv() to
communicate from bhyvectl(8) to bhyve(8).

The idea is that a bhyve process receives a command with with a set of
arguments. The nvlist here is structured to reflect that premise.

For example, to snapshot the vm, the expected nvlist looks like:

{ cmd=START_CHECKPOINT, arg0="filename" }

[rew]

heads up, will commit this revision within the week

[markj]

usr.sbin/bhyve/snapshot.c

1455

Why not call it "path" or so?

usr.sbin/bhyvectl/bhyvectl.c

62–63

I think these should be grouped with the other sys/* includes above?

1719

As a side note, I'm surprised that we don't block until the suspend is finished. bhyvectl has no way to print a useful error message to the invoker if the suspend operation fails...

[rew]

usr.sbin/bhyve/snapshot.c

1455

My logic is that arg0 will be reused for future case statements (i.e., future commands). So when a new command is introduced, it expects X number of arguments. arg0, arg1, arg2, and so on.

Thought it might be easier to keep track of indexed arguments rather than named arguments for the incoming nvlist.

I don't feel strongly about it though. If you think it's short-sighted/confusing to use arg0, let me know and I'll switch it to filename (since its not really a path).

usr.sbin/bhyvectl/bhyvectl.c

1719

Hmm, yea...I'll put this on my radar.

[markj]

usr.sbin/bhyve/snapshot.c

1455

I don't feel strongly about it. I can't see a real downside to using named parameters though, and they're self-describing: I don't have go look around to see what "arg0" is supposed to be, and numbered arguments might be a bit confusing if some of them are optional.

I've never touched the snapshot code so I'll leave it up to you.

[rew]

• drop arg0 in favor of filename
• group/alphabetize sys includes together

Mark, thanks for the feedback.

[jhb]

usr.sbin/bhyve/snapshot.c

1455

I definitely prefer using named variables rather than the argN approach.