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