Back when the original version of this chunk of code was added (commit
41b087198 in libvirt-0.8.1 in April 2010), we used virExecDaemonize()
to start the qemu process, and would continue on in the function
(which at that time was called qemudStartVMDaemon()) even if a -1 was
returned. So it was
Back when macvtap support was added in commit 315baab9443 in Feb. 2010
(libvirt-0.7.7), it was setup to autogenerate a name for the device if
one wasn't supplied, in the pattern "macvtap%d" (or "macvlan%d"),
similar to the way an unspecified standard tap device name will lead
to an autogenerated
On 2020-08-22 15:45, Neal Gompa wrote:
Shouldn't it be fixed the other way? That is, it should know about
DLL, SO, or DYLIB extensions depending on the platform...
Well, there's a myriad of discussions regarding this on projects from
glib
to hexchat (and I read quite a few of them :)...
driver.c and locking/lock_manager.c both hardcode ".so" to
module filenames. In meson, MacOS bundles (loadable objects)
default to using ".dylib" - adding name_suffix as "so" will
therefore align the code with all builds (no need to handle
windows as it doesn't support libvirtd).
Signed-off-by:
On Wed, Aug 19, 2020 at 10:30 AM Andrea Bolognani wrote:
>
> On Wed, 2020-08-19 at 15:10 +0200, Pavel Hrdina wrote:
> > On Wed, Aug 19, 2020 at 02:58:07PM +0200, Andrea Bolognani wrote:
> > > > > We can add an option like it was proposed in V1 but with the following
> > > > > changes. In
On Sat, Aug 22, 2020 at 6:34 PM Scott Shambarger
wrote:
>
> driver.c and locking/lock_manager.c both hardcode ".so" to
> module filenames. In meson, MacOS bundles (loadable objects)
> default to using ".dylib" - adding name_suffix as "so" will
> therefore align the code with all builds (no need
bhyve supports intel hda sound devices that could be specified
on the command like using "-1:0,hda,play=$play_dev,rec=$rec_dev",
where "1:0" is a PCI address, and "$play_dev" and "$rec_dev"
point to the playback and recording device on the host respectively.
Currently, schema of the 'sound'
Changes from v3:
- In conf and bhyve code, cast audio->type to virDomainAudioType and
use switch to make compile force handling of all possible cases,
- Patch 'tests: schema: test bhyvexml2xmloutdata schemas' removed
from the series as it was pushed separately.
Roman Bogorodskiy (5):
Introduce a new device element "" which allows
to map guest sound device specified using the ""
element to specific audio backend.
Example:
This block maps to OSS audio backend on the host using
/dev/dsp0 device for both input (recording)
and output (playback).
Allow to map sound playback and recording devices to host devices
using "" OSS audio backend.
Signed-off-by: Roman Bogorodskiy
---
src/bhyve/bhyve_command.c | 35 +--
src/conf/domain_conf.c| 13 +++
src/conf/domain_conf.h
Document the new element which allows to specify
host audio backend for a guest device, and update
the element description with the new
sub-element which specifies the other end of the mapping.
Signed-off-by: Roman Bogorodskiy
---
docs/formatdomain.rst | 49
Add 'ich7' sound model. This is a preparation for sound support in
bhyve, as 'ich7' is the only model it supports.
Signed-off-by: Roman Bogorodskiy
---
docs/schemas/domaincommon.rng | 1 +
src/conf/domain_conf.c | 1 +
src/conf/domain_conf.h | 1 +
src/qemu/qemu_command.c
On Friday, August 21, 2020 10:05:21 AM, Christian Ehrhardt wrote:
> > , and your
> > suggested change would make these assignments work even on shells that do
> > not apply special parsing rules for it.
>
> Thanks, I also have pushed this through a bunch of tests that use
> libvirt-guests.sh on
13 matches
Mail list logo
