Re: [PATCH v2 1/5] vvfat: introduce partitioned option

["Clément Chigot" <chigot@adacore.com>]

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:
> > 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.
>
> Combined with the option called partinioned=false that's quite unfriendly
> for users trying to type a command line. Maybe not many do but those who
> don't also don't care about what are the defaults or if it's called mbr or
> partitioned as whatever generates the command line for them takes care
> of that. So I'm still for user friendly CLI but I also don't care enough
> to insist more if others don't think it's worth to keep this user friendly
> for command line users.
>
> There was another question if the fat-size option is really needed or it
> could just use size if the default format=raw was changed to behave like
> format=vvfat if file=fat: is given which I think would make more sense
> than only truncating the underlying raw format that's not even needed to
> be there but I don't know how difficult it is to implement this or the
> default format=raw is hard coded and hard to change for fat: protocol.
>
>
> So in summary:
>
> 1. format=vvfat,size=xMB was said to work so could file=fat:/dir,size=xMB
> imply format=vvfat so it would also work? Then no other size option is
> needed.

Well, that discussion was related to patch 5 and my understanding is that:
 1. Having @format=raw,size=xMB forwarding the size to the underlying
VVFAT is not easily doable with our current block architecture.
 2. The @size option for format="raw" is misleading. It should have
been @sliced-size or something close to it. However, it's too late to
change it (or we need to deprecate it in a few releases, but then
outside the scope of this patch).
 3. We want to avoid confusing mistakes, such as forgetting
@format=vvfat and having @size then recognized by @format=raw (the
default). Naming the new option differently ensures a clear error.

Side note, I agree that @fat-size is confusing so I'll rename it @fs-size in V3.

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

Yes, I forgot about that one (though linked to patch 2). If we don't
change the default size of floppy, the existing command lines will
stay as is, hence introducing a new mandatory option is a bad idea.
Overall the tradeoff is "simple default CLI" vs "non-conditional
defaults". Both have pros and cons and I don't have a strong feeling
about which ones should be prefered. So, I'll let you, the
maintainers, decide which one is the best for QEMU, its block devices
and vvfat future ;)

> Regards,
> BALATON Zoltan