On Wed, Nov 5, 2025 at 10:36 AM Kevin Wolf <[email protected]> wrote: > > Am 05.11.2025 um 08:08 hat Markus Armbruster geschrieben: > > Kevin Wolf <[email protected]> writes: > > > > [...] > > > > > To me it looks a bit like what we really want is an enum for floppy > > > sizes (though is there any real reason why we have only those two?), but > > > an arbitrary size for hard disks. > > > > > > Without the enum, obviously, users could specify 1440k and that would do > > > the right thing. Maybe special casing whatever 1.44M and 2.88M result > > > in and translating them into 1440k and 2880k could be more justifiable > > > than special casing 1M and 2M, but it would still be ugly. > > > > > > Markus, do you have any advice how this should be represented in QAPI? > > > > Still want answers here? > > Yes, I'm still not sure how we could best represent both hard disk and > floppy sizes in vvfat in a way that isn't completely counterintuitive > for users, that also isn't just arbitrary magic and that works on the > command line.
For v2 (probably pushed sometimes this week), I've changed the command-line approach to allow only `fat-size=1440K` and `fat-size=2880K`. Other values will be rejected (including `1.44M` or `2.88M`). I'm not familiar with QAPI to see if that approach would fit properly. > Unless the need for different sizes has gone away, but I don't think we > found any other solution for the problem that would not require a > configurable disk/file system size? > > Kevin >
