Changeset View
Standalone View
usr.sbin/bhyve/ipc.h
- This file was added.
/*- | |||||
* SPDX-License-Identifier: BSD-2-Clause-FreeBSD | |||||
* | |||||
* Copyright (c) 2021 Robert Wing <rew@FreeBSD.org> | |||||
* | |||||
* Redistribution and use in source and binary forms, with or without | |||||
* modification, are permitted provided that the following conditions | |||||
* are met: | |||||
* 1. Redistributions of source code must retain the above copyright | |||||
* notice, this list of conditions and the following disclaimer. | |||||
* 2. Redistributions in binary form must reproduce the above copyright | |||||
* notice, this list of conditions and the following disclaimer in the | |||||
* documentation and/or other materials provided with the distribution. | |||||
* | |||||
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND | |||||
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE | |||||
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE | |||||
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE | |||||
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL | |||||
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS | |||||
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) | |||||
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT | |||||
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY | |||||
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF | |||||
* SUCH DAMAGE. | |||||
* | |||||
*/ | |||||
#ifndef _IPC_H_ | |||||
#define _IPC_H_ | |||||
#define BHYVE_RUN_DIR "/var/run/bhyve/" | |||||
#define MAX_SNAPSHOT_FILENAME 100 | |||||
int init_ipc(struct vmctx *); | |||||
/* Filename that will be used for save/restore */ | |||||
struct checkpoint_op { | |||||
char snapshot_filename[MAX_SNAPSHOT_FILENAME]; | |||||
}; | |||||
/* Messages that a bhyve process understands. */ | |||||
enum ipc_opcode { | |||||
START_CHECKPOINT, | |||||
jhb: Might be nice to leave 0 undefined. | |||||
START_SUSPEND, | |||||
}; | |||||
/* | |||||
* The type of message and associated data to | |||||
* send to a bhyve process. | |||||
*/ | |||||
struct ipc_message { | |||||
enum ipc_opcode code; | |||||
union { | |||||
/* | |||||
* message specific structures | |||||
*/ | |||||
struct checkpoint_op op; | |||||
} data; | |||||
jhbUnsubmitted Not Done Inline ActionsCould maybe make the union anonymous and instead use more specific names like 'checkpoint' for the checkpoint_op? jhb: Could maybe make the union anonymous and instead use more specific names like 'checkpoint' for… | |||||
allanjudeUnsubmitted Not Done Inline ActionsOne idea we had had was replacing this struct with an nvlist, so we face far fewer ABI issues when we want to extend the functionality of the control socket. We maybe also want to include a version number, just for future proofing. allanjude: One idea we had had was replacing this struct with an nvlist, so we face far fewer ABI issues… | |||||
jhbUnsubmitted Not Done Inline Actions
My only concern is if we make this too complex it gets a bit hard to use. However, perhaps just using nvlist_send and nvlist_recv over the socket would be ok. Not sure what socket type nvlist expects to use? (SOCK_STREAM vs SOCK_DGRAM vs SOCK_SEQPACKET) jhb: > One idea we had had was replacing this struct with an nvlist, so we face far fewer ABI issues… | |||||
rewAuthorUnsubmitted Not Done Inline ActionsIt looks like nvlist_send() uses send() under the covers; so if I understand correctly, it's expecting either SOCK_STREAM or SOCK_SEQPACKET. If we want to use an nvlist; then I could look into doing one of the following:
My opinon on nvlist vs struct: I could go either way. On one hand it's nice to have a simple/rudimentary interface (plain struct) to see where/if/how the control socket will evolve. One question that comes to mind..what if we want to send a plain struct over the socket? How will an nvlist handle that? At the moment, the only other functionality I'm using the control socket for (using a local patch) is to trigger an ACPI poweroff from bhyvectl. rew: It looks like `nvlist_send()` uses `send()` under the covers; so if I understand correctly… | |||||
rewAuthorUnsubmitted Done Inline ActionsI've made the changes to allow nvlist_send()/nvlist_recv() to work with SOCK_DGRAM. I'll get a review up shortly for bhyve to use an nvlist instead. rew: I've made the changes to allow nvlist_send()/nvlist_recv() to work with SOCK_DGRAM.
I'll get a… | |||||
}; | |||||
#endif /* _IPC_H_ */ |
Might be nice to leave 0 undefined.