All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: "Clément Chigot" <chigot@adacore.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	 qemu-devel@nongnu.org, hreitz@redhat.com,
	 qemu-block@nongnu.org
Subject: Re: [PATCH 5/5] vvfat: add support for "size" options
Date: Mon, 27 Oct 2025 13:09:26 +0100	[thread overview]
Message-ID: <87ms5cmtqh.fsf@pond.sub.org> (raw)
In-Reply-To: <CAJ307EjFXNyEwDTeXEwdc02PxBLHGENbPJCM+-v_6FRQ2VYEcw@mail.gmail.com> ("Clément Chigot"'s message of "Fri, 24 Oct 2025 11:23:00 +0200")

Clément Chigot <chigot@adacore.com> writes:

> On Fri, Oct 24, 2025 at 10:35 AM Markus Armbruster <armbru@redhat.com> wrote:
>>
>> Kevin Wolf <kwolf@redhat.com> writes:
>>
>> > Am 03.09.2025 um 09:57 hat Clément Chigot geschrieben:
>> >> This allows more flexibility to vvfat backend. The value for "Number of
>> >> Heads" and "Sectors per track" are based on SD specifications Part 2.
>>
>> This is too terse to remind me of how vvfat picks cylinders, heads, and
>> sectors before this patch, so I need to go dig through the source code.
>> I figure it depends on configuration parameters @floppy and @fat-type
>> like this:
>>
>>     floppy  fat-type    cyls heads secs   cyls*heads*secs*512
>>     false      12         64    16   63         31.5 MiB
>>     false      16       1024    16   63        504   MiB
>>     false      32       1024    16   63        504   MiB
>>     true       12         80     2   18       1440   KiB
>>     true       16         80     2   36       2880   KiB
>>     true       32         80     2   36       2880   KiB
>>
>> How exactly does the new parameter @size change this?
>
> My prime goal was to create a 256 Mib VVFAT disk. As you can see,
> today for hard-disks there are only two possibilities: 31.5 Mib or 504
> Mib. Hence, I've introduced the option `size=xxx` to allow more
> granular choices.
> This option changes how cyls, heads and secs parameters are computed
> to be as closed as possible of its value.
>
> I did try to keep it simple. I could have introduced options to select
> cylinders, heads, etc. But I think "size=xxx" would be more intuitive.
> There are also approximations made, as not all sizes can be reached. I
> didn't add errors or warnings for them. I'm fine adding them.

I don't have an opinion on whether we should support more sizes and/or
provide full control over CHS geometry.

>> >> Some limitations remains, the size parameter is recognized only when
>> >> "format=vvfat" is passed. In particular, "format=raw,size=xxx" is
>> >> keeping the previously hardcoded value: 504MB for FAT16 and 32 MB for
>> >> FAT12. FAT32 has not been adjusted and thus still default to 504MB.
>>
>> 31.5MiB unless I'm mistaken.
>
> True, I will fix it.
>
>> I'm not sure what you're trying to convey in this paragraph.  As far as
>> I can tell, you're adding a @size parameter to vvfat, so of course it
>> doesn't affect raw.
>
> Yes, but AFAICT, `if=sd,format=raw` will result in vvfat backend being
> called. I didn't manage to make the new option work with
> `if=sd,format=raw,size=256Mb`. Thus, when the "size" option is not
> provided, I keep the previous value (those for your above comment).
> Hence this paragraph to mostly warn people about the current
> limitation.

Are you talking about -drive?

Complete examples, please.

I'm confused about the connection between SD (from if=sd here, and "SD
specification" above) and vvfat.  SD is a frontend.  vvfat is a backend.

[...]



  reply	other threads:[~2025-10-27 12:10 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-03  7:57 [PATCH 0/5] block/vvfat: introduce "size" option Clément Chigot
2025-09-03  7:57 ` [PATCH 1/5] vvfat: introduce no-mbr option Clément Chigot
2025-10-23 18:20   ` Kevin Wolf
2025-10-29  8:37     ` Clément Chigot
2025-10-29 10:56       ` Kevin Wolf
2025-10-29 13:44         ` Clément Chigot
2025-09-03  7:57 ` [PATCH 2/5] vvfat: move fat_type check prior to size setup Clément Chigot
2025-10-23 18:39   ` Kevin Wolf
2025-10-29 13:48     ` Clément Chigot
2025-10-29 13:58       ` BALATON Zoltan
2025-10-29 16:05         ` Kevin Wolf
2025-09-03  7:57 ` [PATCH 3/5] vvfat: add a define for SECTOR_SIZE Clément Chigot
2025-10-23 18:47   ` Kevin Wolf
2025-09-03  7:57 ` [PATCH 4/5] vvfat: move size parameters within driver structure Clément Chigot
2025-09-03  7:57 ` [PATCH 5/5] vvfat: add support for "size" options Clément Chigot
2025-10-23 19:29   ` Kevin Wolf
2025-10-24  8:30     ` Markus Armbruster
2025-10-24  9:23       ` Clément Chigot
2025-10-27 12:09         ` Markus Armbruster [this message]
2025-10-28 14:54           ` Clément Chigot
2025-10-31  7:46             ` Markus Armbruster
2025-10-31  9:47               ` Clément Chigot
2025-10-31 11:56                 ` Kevin Wolf
2025-10-31 13:07                   ` Clément Chigot
2025-11-05  7:06                     ` Markus Armbruster
2025-11-05  7:08     ` Markus Armbruster
2025-11-05  9:35       ` Kevin Wolf
2025-11-05 10:15         ` Clément Chigot
2025-11-07  8:06         ` Markus Armbruster
2025-09-15  8:47 ` [PATCH 0/5] block/vvfat: introduce "size" option Clément Chigot
2025-10-07  7:43 ` Clément Chigot
2025-11-12 12:38 ` Richard W.M. Jones
2025-11-12 13:09   ` Clément Chigot
2025-11-13  8:41   ` Kevin Wolf
2025-11-13  9:13     ` Richard W.M. Jones
2025-11-13 13:13       ` Kevin Wolf

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=87ms5cmtqh.fsf@pond.sub.org \
    --to=armbru@redhat.com \
    --cc=chigot@adacore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.