[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.