On Fri, Nov 14, 2025 at 2:25 PM BALATON Zoltan <[email protected]> wrote: > > On Fri, 14 Nov 2025, Clément Chigot wrote: > > On Tue, Nov 11, 2025 at 8:43 AM Markus Armbruster <[email protected]> wrote: > >> > >> Kevin Wolf <[email protected]> writes: > >> > >>> Am 10.11.2025 um 14:20 hat Markus Armbruster geschrieben: > >>>> BALATON Zoltan <[email protected]> writes: > >>>> > >>>>> On Mon, 10 Nov 2025, Clément Chigot wrote: > >>>>>> On Mon, Nov 10, 2025 at 11:07 AM Markus Armbruster <[email protected]> > >>>>>> wrote: > >>>>>>> > >>>>>>> Clément Chigot <[email protected]> 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 <[email protected]> > >> > >> [...] > >> > >>>>>>> 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
