From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6A5BFC4332F for ; Tue, 31 Oct 2023 18:45:29 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qxtiy-0004Pl-JE; Tue, 31 Oct 2023 14:44:24 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qxtix-0004PE-Eq for qemu-devel@nongnu.org; Tue, 31 Oct 2023 14:44:23 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qxtiv-0003M1-En for qemu-devel@nongnu.org; Tue, 31 Oct 2023 14:44:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1698777860; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=UjS5fhVfmjwrYA5hiqIOKQ/kGKfc3sWo8fSCrZ2b8sk=; b=h7XFDVNdCl2fr6rozDjcGMP5QS030yVybjVub0u72C2NR4Eoa8+z33re8PXdcznolMO208 FeERBDsn5LwT/q+qjUJMCXV9TZriFurSUCw+yI2pklMYwRa+jtZEWJpstafPuAOBKaP6ub 4dL4rgAljsPfWiH1mxQ4kDsgMUW/Ll8= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-589-8hl5LysdOlqwGsLizwlSzg-1; Tue, 31 Oct 2023 14:44:15 -0400 X-MC-Unique: 8hl5LysdOlqwGsLizwlSzg-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 453FC88FC2E; Tue, 31 Oct 2023 18:44:15 +0000 (UTC) Received: from redhat.com (unknown [10.39.194.218]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C80142166B26; Tue, 31 Oct 2023 18:44:13 +0000 (UTC) Date: Tue, 31 Oct 2023 19:44:12 +0100 From: Kevin Wolf To: Michael Tokarev Cc: QEMU Developers , "open list:Network Block Dev..." , BALATON Zoltan , "Daniel P. Berrange" , Paolo Bonzini Subject: Re: -drive if=none: can't we make this the default? Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.6 Received-SPF: pass client-ip=170.10.129.124; envelope-from=kwolf@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.481, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Hi Michael, I didn't see this thread when you posted it, sorry for being a bit late. Am 16.10.2023 um 13:58 hat Michael Tokarev geschrieben: > Almost everyone mentions -blockdev as a replacement for -drive. More specifically for -drive if=none. I honestly don't know many common use cases for that one. For management tools, -blockdev is indeed what should be used, and that things are more explicit there is actually a feature, not a bug, for management tools. As a human user, in the common case where I don't care about the details, I don't want to type up an explicit -device. if=virtio gives me more directly what I want. So you only need it when you want to specify one of the more exotic -device options, which shouldn't happen that often. Well, it doesn't for me anyway, other people may have other use cases. Is that your case? If so, which options do you usually want to give to -device? > But I have to remind several issues with it: > > 1. While documentation has improved a lot, -blockdev is still mostly unknown > to the masses. And for manual human use, that's okay anyway - you probably don't want to use it. But if you're writing scripts or even advanced management software, then you should use it. (Of course, in complex cases you may have to use it manually anyway because -drive has some limitations, but that should be the absolute exception.) > 2. -blockdev is just too verbose, one have to specify a lot of parameters just to > do a simple thing which is solved with an extra parameter with -drive. > Including various backing stores/chains for qcow2 files - this is terrible for > using things manually from command line You don't have to specify the backing chain explicitly if you're happy with the default options with which the backing files are opened. -blockdev options are typically a bit longer than -drive ones, but not extremely. The separate -device that if=none gives you is already a similar amount of extra typing. -drive if=virtio,file=test.qcow2 -drive if=none,file=test.qcow2,id=disk -device virtio-blk,drive=disk -blockdev qcow2,file.driver=file,file.filename=test.qcow2,node-name=disk -device virtio-blk,drive=disk > 3. -blockdev does not work with -snapshot > > 4. Something else I forgot while typing all the above :) > > In my view, -blockdev is not a substitute for -drive, not at all, and it is > very user-unfriendly. This is why -drive seems to be a good trade-off between > things like -hda (which is just too simplistic) and -blockdev which which is > way too verbose and lacks some automatic sugar like -snapshot. I would agree with that, but if=none already feels a bit unfriendly. Honestly, I would like to throw away the existing -drive and replace it with one that has a simpler implementation (as a wrapper around -blockdev) and I would be happy if it gained some additional options for passing through things to -device so that you don't have to bother with if=none even in the more complex cases any more. It would be pure syntactic sugar with a similar compatibility promise as in HMP (we won't break it just for fun, but we'll also not stop making sensible changes just because they make things look a bit different). Kevin