On 11/20/19 7:02 PM, Cole Robinson wrote:
I see your points but I still favor the old way. There's no rush to
change this IMO so maybe we can come up with consensus on whether it's
optimal to put default supported=yes|no values in common code or not.
CCing Jano and Michal for their opinions too.
On Wed, Nov 20, 2019 at 13:02:04 -0500, Cole Robinson wrote:
> On 11/20/19 9:40 AM, Peter Krempa wrote:
> > On Mon, Nov 18, 2019 at 14:43:08 -0500, Cole Robinson wrote:
> >> On 11/13/19 11:05 AM, Peter Krempa wrote:
> >>> For future extensions of the domain caps it's useful to have a single
> >>>
On 11/20/19 9:40 AM, Peter Krempa wrote:
> On Mon, Nov 18, 2019 at 14:43:08 -0500, Cole Robinson wrote:
>> On 11/13/19 11:05 AM, Peter Krempa wrote:
>>> For future extensions of the domain caps it's useful to have a single
>>> point that initializes all capabilities as unsupported by a driver. The
On Mon, Nov 18, 2019 at 14:43:08 -0500, Cole Robinson wrote:
> On 11/13/19 11:05 AM, Peter Krempa wrote:
> > For future extensions of the domain caps it's useful to have a single
> > point that initializes all capabilities as unsupported by a driver. The
> > driver then can enable specific ones.
>
On 11/13/19 11:05 AM, Peter Krempa wrote:
> For future extensions of the domain caps it's useful to have a single
> point that initializes all capabilities as unsupported by a driver. The
> driver then can enable specific ones.
>
> Signed-off-by: Peter Krempa
> ---
>
On Wed, Nov 13, 2019 at 05:05:23PM +0100, Peter Krempa wrote:
For future extensions of the domain caps it's useful to have a single
point that initializes all capabilities as unsupported by a driver. The
driver then can enable specific ones.
Signed-off-by: Peter Krempa
---
For future extensions of the domain caps it's useful to have a single
point that initializes all capabilities as unsupported by a driver. The
driver then can enable specific ones.
Signed-off-by: Peter Krempa
---
src/bhyve/bhyve_capabilities.c | 4 +---
src/conf/domain_capabilities.c | 14
