Kevin Wolf <kwolf@xxxxxxxxxx> writes: > Am 03.04.2023 um 15:49 hat Alex Bennée geschrieben: >> We are a bit premature in recommending -blockdev/-device as the best >> way to configure block devices, especially in the common case. >> Improve the language to hopefully make things clearer. >> >> Suggested-by: Michael Tokarev <mjt@xxxxxxxxxx> >> Signed-off-by: Alex Bennée <alex.bennee@xxxxxxxxxx> >> Reviewed-by: Thomas Huth <thuth@xxxxxxxxxx> >> Message-Id: <20230330101141.30199-5-alex.bennee@xxxxxxxxxx> >> --- >> qemu-options.hx | 8 ++++++-- >> 1 file changed, 6 insertions(+), 2 deletions(-) >> >> diff --git a/qemu-options.hx b/qemu-options.hx >> index 59bdf67a2c..9a69ed838e 100644 >> --- a/qemu-options.hx >> +++ b/qemu-options.hx >> @@ -1143,10 +1143,14 @@ have gone through several iterations as the feature set and complexity >> of the block layer have grown. Many online guides to QEMU often >> reference older and deprecated options, which can lead to confusion. >> >> -The recommended modern way to describe disks is to use a combination of >> +The most explicit way to describe disks is to use a combination of >> ``-device`` to specify the hardware device and ``-blockdev`` to >> describe the backend. The device defines what the guest sees and the >> -backend describes how QEMU handles the data. >> +backend describes how QEMU handles the data. The ``-drive`` option >> +combines the device and backend into a single command line options >> +which is useful in the majority of cases. Older options like ``-hda`` >> +bake in a lot of assumptions from the days when QEMU was emulating a >> +legacy PC, they are not recommended for modern configurations. > > Let's not make the use of -drive look more advisable than it really is. > If you're writing a management tool/script and you're still using -drive > today, you're doing it wrong. > > Maybe this is actually the point where we should just clearly define > that -blockdev is the only supported stable API (like QMP), and that > -drive etc. are convenient shortcuts for human users with no > compatibility promise (like HMP). OK I'll drop this patch from today's PR and await a better description in due course. > > What stopped us from doing so is that there are certain boards that > don't allow the user to configure the onboard devices, but that look at > -drive. These wouldn't provide any stable API any more after this > change. However, if this hasn't been solved in many years, maybe it's > time to view it as the board's problem, and use this change to motivate > them to implement ways to configure the devices. Or maybe some don't > even want to bother with a stable API, who knows. > > Kevin -- Alex Bennée Virtualisation Tech Lead @ Linaro
