qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: "Clément Chigot" <chigot@adacore.com>
Cc: Markus Armbruster <armbru@redhat.com>,
	qemu-block@nongnu.org, qemu-devel@nongnu.org, hreitz@redhat.com,
	eblake@redhat.com, BALATON Zoltan <balaton@eik.bme.hu>
Subject: Re: [PATCH v2 1/5] vvfat: introduce partitioned option
Date: Wed, 26 Nov 2025 20:27:13 +0100	[thread overview]
Message-ID: <aSdUfZsqipQ4gacW@redhat.com> (raw)
In-Reply-To: <CAJ307EjdoHZjSYCt7TKSLo=hqDS7y_azUBYsQszh3cAKG3jU-A@mail.gmail.com>

Am 26.11.2025 um 10:59 hat Clément Chigot geschrieben:
> On Fri, Nov 14, 2025 at 2:47 PM Clément Chigot <chigot@adacore.com> wrote:
> > On Fri, Nov 14, 2025 at 2:25 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
> > > On Fri, 14 Nov 2025, Clément Chigot wrote:
> > > > 1. "mbr" vs "partitioned".
> > > > I do think "partitioned" is clearer, a bit more casual friendly. "mbr"
> > > > requires knowledge about FAT format, while what's a partition should
> > > > be known by a wider audience.
> > > > Side note, in V3, I'll remove the "unpartitioned" keyword to simply
> > > > replace it by "partitoned=false" (I wasn't aware such an obvious
> > > > possibility was working...). So we might even call it
> > > > "partition/partitions=true|false".

As I said, either one works for me.

> > > > 2. The default value. Should it be "false" for @floppy ?
> > > > IMO, having a default value independent of other arguments is always
> > > > better. Hence, I'll push for keeping "partitioned=true" as the
> > > > default, and having users forcing "partitioned=false" for floppy (an
> > > > error being raised otherwise). As we'll probably change the default
> > > > behavior with floppy anyway (cf patch 2), I don't think it will hurt a
> > > > lot to make users passing a new flag.

I'm very much in favour of defaulting to partitioned for hard disks and
unpartitioned for floppies. This is not only the option that stays most
compatible with what we have in existing QEMU versions, but also the
most intuitive setting.

With the change to the default behaviour with floppy, we were forced to
pick between options that all meant changing the default, so I proposed
taking the most intuitive default there, too: I'm relatively sure that
when you mention floppy, most people will think of 1.44 MB first.

> > > 2. Having different defaults for floppy or disk would keep existing
> > > command lines working. Otherwise why not make partitioned=false the
> > > default and let users who need it set explicitly. That would also
> > > work for most cases without having to type out this option.

Slightly better than an unconditional partitioned=true default and
getting partitioned floppies, which is most definitely unexpected. But
it's still not usually the thing the user will want with hard disks, so
as I said above, I prefer the conditional default here.

Kevin



  reply	other threads:[~2025-11-26 19:28 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-07 14:53 [PATCH v2 0/5] block/vvfat: introduce "fat-size" option Clément Chigot
2025-11-07 14:53 ` [PATCH v2 1/5] vvfat: introduce partitioned option Clément Chigot
2025-11-10 10:07   ` Markus Armbruster
2025-11-10 11:09     ` Clément Chigot
2025-11-10 12:55       ` BALATON Zoltan
2025-11-10 13:20         ` Markus Armbruster
2025-11-10 15:08           ` Kevin Wolf
2025-11-10 15:25             ` BALATON Zoltan
2025-11-11  7:43             ` Markus Armbruster
2025-11-14  8:20               ` Clément Chigot
2025-11-14 13:25                 ` BALATON Zoltan
2025-11-14 13:47                   ` Clément Chigot
2025-11-26  9:59                     ` Clément Chigot
2025-11-26 19:27                       ` Kevin Wolf [this message]
2025-11-07 14:53 ` [PATCH v2 2/5] vvfat: move fat_type check prior to size setup Clément Chigot
2025-11-10 10:09   ` Markus Armbruster
2025-11-10 11:15     ` Clément Chigot
2025-11-10 13:13       ` Markus Armbruster
2025-11-10 15:29         ` Kevin Wolf
2025-11-11  8:16           ` Markus Armbruster
2025-11-11  8:17           ` Markus Armbruster
2025-11-07 14:53 ` [PATCH v2 3/5] vvfat: add a define for VVFAT_SECTOR_BITS and VVFAT_SECTOR_SIZE Clément Chigot
2025-11-07 14:53 ` [PATCH v2 4/5] vvfat: move size parameters within driver structure Clément Chigot
2025-11-07 14:53 ` [PATCH v2 5/5] vvfat: add support for "fat-size" options Clément Chigot
2025-11-10 10:13   ` Markus Armbruster
2025-11-10 12:46     ` Clément Chigot
2025-11-10 13:09       ` Markus Armbruster
2025-11-10 13:26         ` Clément Chigot
2025-11-10 13:42           ` Markus Armbruster
2025-11-10 14:04             ` Clément Chigot
2025-11-10 15:20             ` Kevin Wolf
2025-11-10 15:36               ` BALATON Zoltan
2025-11-10 16:31                 ` Kevin Wolf
2025-11-10 21:36                   ` BALATON Zoltan
2025-11-12  9:50                   ` Clément Chigot
2025-11-12 12:29                     ` Kevin Wolf
2025-11-11  7:59               ` Markus Armbruster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aSdUfZsqipQ4gacW@redhat.com \
    --to=kwolf@redhat.com \
    --cc=armbru@redhat.com \
    --cc=balaton@eik.bme.hu \
    --cc=chigot@adacore.com \
    --cc=eblake@redhat.com \
    --cc=hreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).