qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Clément Chigot" <chigot@adacore.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	BALATON Zoltan <balaton@eik.bme.hu>,
	qemu-block@nongnu.org,  qemu-devel@nongnu.org, hreitz@redhat.com,
	eblake@redhat.com
Subject: Re: [PATCH v2 1/5] vvfat: introduce partitioned option
Date: Fri, 14 Nov 2025 09:20:54 +0100	[thread overview]
Message-ID: <CAJ307EjFMrXOmQMF5YckQ6hMGdFGtdYdAH3fWShcvwEXAtBrrw@mail.gmail.com> (raw)
In-Reply-To: <87ecq5f201.fsf@pond.sub.org>

On Tue, Nov 11, 2025 at 8:43 AM Markus Armbruster <armbru@redhat.com> wrote:
>
> Kevin Wolf <kwolf@redhat.com> writes:
>
> > Am 10.11.2025 um 14:20 hat Markus Armbruster geschrieben:
> >> BALATON Zoltan <balaton@eik.bme.hu> writes:
> >>
> >> > On Mon, 10 Nov 2025, Clément Chigot wrote:
> >> >> On Mon, Nov 10, 2025 at 11:07 AM Markus Armbruster <armbru@redhat.com> wrote:
> >> >>>
> >> >>> Clément Chigot <chigot@adacore.com> writes:
> >> >>>
> >> >>>> This option tells whether a hard disk should be partitioned or not. It
> >> >>>> defaults to true and have the prime effect of preventing a master boot
> >> >>>> record (MBR) to be initialized.
> >> >>>>
> >> >>>> This is useful as some operating system (QNX, Rtems) don't
> >> >>>> recognized FAT mounted disks (especially SD cards) if a MBR is present.
> >> >>>>
> >> >>>> Signed-off-by: Clément Chigot <chigot@adacore.com>
>
> [...]
>
> >> >>> Not sure I like "partitioned".  Is a disk with an MBR and a partition
> >> >>> table contraining a single partition partitioned?  Call it "mbr"?
> >> >>
> >> >> It used to be called "mbr/no-mbr" but Kevin suggested renaming it in
> >> >> V1. Honestly I'm fine with both options:
> >> >> - Technically, the option prevents MBR which has a side effect for
> >> >> preventing partition tables
> >>
> >> Yes, because the partition table is part of the MBR.  I'd rather name
> >> the option after the entire thing it controls, not one of its parts.
> >>
> >> >> - Even it has a single partition, I think it makes sense to call a
> >> >> disk "partitioned" as long as it has a partition table
> >> >>
> >> >> But I'm not that familiar with disk formats, etc. I'll let you decide
> >> >> with Kevin, which one you prefer.
> >>
> >> Kevin is the maintainer, I just serve as advisor here.
> >
> > I figured that the meaning of "partitioned" is easier to understand for
> > a casual user than having or not having an MBR ("I don't want to boot
> > from this disk, why would I care about a boot record?").
>
> Fair point.
>
> Possible counter-points:
>
> * The default is almost always right for the casual user.  The
>   exception, as far as I understand, is certain guest OSes refuse to
>   play ball with certain devices when they have an MBR.
>
> * The configuration interface isn't exactly casual-user-friendly to
>   begin with.  @fat-type, what's that, and why do I care?  @floppy,
>   what's that, and why do I care?
>
> Anyway, you decide.

AFAICT, there are two open questions for that patch:

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

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.

> > But if people think that "mbr" is better, that's fine with me.
> >
> > The only thing I really didn't want is the negative "no-mbr" and the
> > double negation in "no-mbr=off" that comes with it.
>
> Yes, negative names should definitely be avoided for boolean options.
>
> [...]
>


  reply	other threads:[~2025-11-14  8:22 UTC|newest]

Thread overview: 35+ 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 [this message]
2025-11-14 13:25                 ` BALATON Zoltan
2025-11-14 13:47                   ` Clément Chigot
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=CAJ307EjFMrXOmQMF5YckQ6hMGdFGtdYdAH3fWShcvwEXAtBrrw@mail.gmail.com \
    --to=chigot@adacore.com \
    --cc=armbru@redhat.com \
    --cc=balaton@eik.bme.hu \
    --cc=eblake@redhat.com \
    --cc=hreitz@redhat.com \
    --cc=kwolf@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).