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_ | |||||||||
int init_ipc(struct vmctx *); | |||||||||
#endif /* _IPC_H_ */ | |||||||||
jhb: Could maybe make the union anonymous and instead use more specific names like 'checkpoint' for… | |||||||||
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… | |||||||||
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… | |||||||||
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… | |||||||||
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… | |||||||||
Done Inline Actions
Might be nice to leave 0 undefined. jhb: Might be nice to leave 0 undefined. |
Could maybe make the union anonymous and instead use more specific names like 'checkpoint' for the checkpoint_op?