qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] -device foo, help shouldn't be allowed for devices wher


From: Markus Armbruster
Subject: Re: [Qemu-devel] -device foo, help shouldn't be allowed for devices where -device foo is forbidden
Date: Tue, 15 Jan 2019 08:23:40 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Peter Maydell <address@hidden> writes:

> On Mon, 14 Jan 2019 at 16:59, Thomas Huth <address@hidden> wrote:
>>
>> On 2019-01-14 17:31, Peter Maydell wrote:
>> > We prohibit -device foo for non-pluggable devices:
>> > $ ./build/all/x86_64-softmmu/qemu-system-x86_64 -device i8257
>> > qemu-system-x86_64: -device i8257: Parameter 'driver' expects
>> > pluggable device type
>> >
>> > And we suppress them from "-device help" output too.
>> >
>> > But we still allow the user to do this:
>> >
>> > $ ./build/all/x86_64-softmmu/qemu-system-x86_64 -device i8257,help
>> > i8257 options:
>> >   dshift=<int32>
>> >   base=<int32>
>> >   pageh-base=<int32>
>> >   page-base=<int32>
>>
>> Could this still be sometimes useful, e.g. when a device is configured
>> with the "-global" parameter?

That's exactly why we provide this help.  Admittedly obscure.

> Hmm, good point: some of the properties are usefully human
> changeable even for built-in devices. But a lot of them
> are not, if you look at the iotkit example.
> Perhaps a useful compromise would be filtering out the
> "child<" properties? (these are all created via
> object_property_add_child() and user changes to them seem
> unlikely to be ever something that would work).

As long as "seem unlikely to be ever" actually means "are not going to
be", no objection.  I doubt it's worth the effort, though.

A worthier goal would be getting -global to provide help.  Sadly, that
doesn't seem practical in the current state of things.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]