blob: de0423fdbd8d2541bc20afec8b4575cd1e280557 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
|
mistranslation: 0.890
other: 0.885
semantic: 0.875
device: 0.636
instruction: 0.596
graphic: 0.469
boot: 0.282
vnc: 0.258
network: 0.202
socket: 0.196
assembly: 0.194
KVM: 0.139
'none' machine should use 'none' display option
As the 'none' machine doesn't have any peripheral (except CPU cores)
it is pointless to start a display.
'-M none' should imply '-display none'.
Could be as simple as setting MachineClass->default_display = "none" ... have you tried whether that's working as expected?
Actually, thinking about this twice, I think you made a wrong assumption here. "-display" is about the GUI backend that should be used. "-M" is about the emulated hardware. The emulated hardware options should never influence the host backend options. And it is e.g. perfectly valid to use the "none" machine as CPU instruction simulator in a GTK window, so it does not make sense to force the disablement the GUI in that case.
> I think you made a wrong assumption here. "-display" is
> about the GUI backend that should be used. "-M" is about
> the emulated hardware. The emulated hardware options
> should never influence the host backend options.
Aright. What confuses me is having serial0/parallel0 chardevs
initialized when using the none-machine. I realized when
looking at your suggestion in comment #1 that the chardevs
(among other hardware related things) are initialized in
qemu_init().
I started testing using:
bool is_none_machine = !strcmp(machine_class->name,
MACHINE_TYPE_NAME("none"));
and disabling blocks of code with:
if (!is_none_machine) {
...
}
then planned to update this ticket description but you beat
me. I'll open a different issue.
|