Kevin Wolf <[email protected]> writes: > Am 10.11.2025 um 14:13 hat Markus Armbruster geschrieben: >> Clément Chigot <[email protected]> writes: >> >> > On Mon, Nov 10, 2025 at 11:09 AM Markus Armbruster <[email protected]> >> > wrote: >> >> >> >> Clément Chigot <[email protected]> writes: >> >> >> >> > This allows to handle the default FAT size in a single place and make >> >> > the >> >> > following part taking care only about size parameters. It will be later >> >> > moved away in a specific function. >> >> > >> >> > The selection of floppy size was a bit unusual: >> >> > - fat-type undefined: a FAT 12 2880 Kib disk (default) >> >> > - fat-type=16: a FAT 16 2880 Kib disk >> >> > - fat-type=12: a FAT 12 1440 Kib disk >> >> > >> >> > Now, that fat-type undefined means fat-type=12, it's no longer possible >> >> > to make that size distinction. Therefore, it's being changed for the >> >> > following: >> >> > - fat-type=12: a FAT 12 1440 Kib disk (default) >> >> > - fat-type=16: a FAT 16 2880 Kib dis >> >> > >> >> > This has been choosen for two reasons: keep fat-type=12 the default and >> >> > creates a more usual size for it: 1440 Kib. >> >> > >> >> > The possibility to create a FAT 12 2880 Kib floppy will be added back >> >> > later, through the fat-size parameter. >> >> > >> >> > Side note to mention that s->sectors_per_cluster assignments are >> >> > removed because they are overidden a few line further. >> >> > >> >> > Signed-off-by: Clément Chigot <[email protected]> >> >> >> >> Is this a user-visible change? >> > >> > Yes, just "floppy" will now result in a 1440 KiB instead of the >> > previous 2880 KiB. However, Kevin mentions in V1 that it would make >> > more sense and vvfat being known to be unstable, this would be fine. >> > FTR, here is the complete comment: >> > >> >> On Wed, Oct 29, 2025 at 5:06 PM Kevin Wolf <[email protected]> wrote: >> >> > In general, our stance is that we can change defaults whenever we want >> >> > to, and if you don't want to be surprised by changing defaults, you need >> >> > to specify the option explicitly. >> >> Hmm, where is this stance on defaults documented? Question for Kevin, >> of course. > > Probably nowhere. More importantly, I don't think a compatibility > promise that says otherwise is documented either. And we know that > defaults have changed before, and that libvirt tries to be as explicit > as possible to avoid being impacted by changed defaults. > > Do you disagree? If so, is there any way to change defaults or do we > have to stick to the existing defaults forever? To me not specifying an > option means "just pick anything that makes sense", without any promise > that this stays the same across versions.
I'd love to be able to change defaults. Defaults can become bad over time. I remember arguing for changing such defaults unsuccessfully. Looks like there's differing opinions / uncertainty on whether our compatibility promise covers defaults. That's bad, we need clarity there. I'll start a separate thread. [...]
