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 1EEF2CCFA13 for ; Mon, 10 Nov 2025 13:40:54 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1vIS7d-0001yz-PR; Mon, 10 Nov 2025 08:39:55 -0500 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 1vIRiD-0002fs-Qm for qemu-devel@nongnu.org; Mon, 10 Nov 2025 08:13:39 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1vIRi0-0008Lz-M3 for qemu-devel@nongnu.org; Mon, 10 Nov 2025 08:13:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1762780400; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7g9xL0RxGsoNnu+JdIUsQjWaA7KiC/WAha5ownuBQTc=; b=UkhP9QnOZA1aKqo5vrtsSLpGe+OVecTrolgqAo9KebqZHrSqpLGy5q8Y9qbBNty0HHqknl rMTAMnSwYaVpAGU3G6Sgp4LqBIJwpPyiX0dCVKncVzpKcj1AXR5XdNLNCaLs/vgKxw4L3Q DFUZuFJFMp85NroLIYfQNrw8RImceV0= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-618-F2siaPzsN4aSWccHaSG0wA-1; Mon, 10 Nov 2025 08:13:17 -0500 X-MC-Unique: F2siaPzsN4aSWccHaSG0wA-1 X-Mimecast-MFC-AGG-ID: F2siaPzsN4aSWccHaSG0wA_1762780396 Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (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 mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 6F9F31956089; Mon, 10 Nov 2025 13:13:16 +0000 (UTC) Received: from blackfin.pond.sub.org (unknown [10.45.242.18]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id DB34F19560A7; Mon, 10 Nov 2025 13:13:15 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id 276E721E6A27; Mon, 10 Nov 2025 14:13:13 +0100 (CET) From: Markus Armbruster To: =?utf-8?Q?Cl=C3=A9ment?= Chigot Cc: qemu-block@nongnu.org, qemu-devel@nongnu.org, kwolf@redhat.com, hreitz@redhat.com, eblake@redhat.com Subject: Re: [PATCH v2 2/5] vvfat: move fat_type check prior to size setup In-Reply-To: (=?utf-8?Q?=22Cl=C3=A9ment?= Chigot"'s message of "Mon, 10 Nov 2025 12:15:20 +0100") References: <20251107145327.539481-1-chigot@adacore.com> <20251107145327.539481-3-chigot@adacore.com> <874ir2nqr9.fsf@pond.sub.org> Date: Mon, 10 Nov 2025 14:13:13 +0100 Message-ID: <877bvykp3q.fsf@pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 Received-SPF: pass client-ip=170.10.133.124; envelope-from=armbru@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham 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 Cl=C3=A9ment Chigot writes: > On Mon, Nov 10, 2025 at 11:09=E2=80=AFAM Markus Armbruster wrote: >> >> Cl=C3=A9ment Chigot writes: >> >> > This allows to handle the default FAT size in a single place and make = the >> > following part taking care only about size parameters. It will be later >> > moved away in a specific function. >> > >> > The selection of floppy size was a bit unusual: >> > - fat-type undefined: a FAT 12 2880 Kib disk (default) >> > - fat-type=3D16: a FAT 16 2880 Kib disk >> > - fat-type=3D12: a FAT 12 1440 Kib disk >> > >> > Now, that fat-type undefined means fat-type=3D12, it's no longer possi= ble >> > to make that size distinction. Therefore, it's being changed for the >> > following: >> > - fat-type=3D12: a FAT 12 1440 Kib disk (default) >> > - fat-type=3D16: a FAT 16 2880 Kib dis >> > >> > This has been choosen for two reasons: keep fat-type=3D12 the default = and >> > creates a more usual size for it: 1440 Kib. >> > >> > The possibility to create a FAT 12 2880 Kib floppy will be added back >> > later, through the fat-size parameter. >> > >> > Side note to mention that s->sectors_per_cluster assignments are >> > removed because they are overidden a few line further. >> > >> > Signed-off-by: Cl=C3=A9ment Chigot >> >> Is this a user-visible change? > > Yes, just "floppy" will now result in a 1440 KiB instead of the > previous 2880 KiB. However, Kevin mentions in V1 that it would make > more sense and vvfat being known to be unstable, this would be fine. > FTR, here is the complete comment: > >> On Wed, Oct 29, 2025 at 5:06=E2=80=AFPM Kevin Wolf wr= ote: >> > In general, our stance is that we can change defaults whenever we want >> > to, and if you don't want to be surprised by changing defaults, you ne= ed >> > to specify the option explicitly. Hmm, where is this stance on defaults documented? Question for Kevin, of course. >> > What's a bit strange about the vvfat >> > interface is that the default actually represents a configuration that >> > can't even be expressed explicitly at the moment. Awkward. >> > So it is a special case in a way, but given that this is vvfat, which = is >> > known to be unstable, not widely used outside of the occasional manual >> > use and not supported by libvirt, I'm willing to just make the change. I'm fine to treat vvfat as unstable. But it's not marked as such in the QAPI schema! Is that a bug? Again, for Kevin.