All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: "Richard W.M. Jones" <rjones@redhat.com>
Cc: "Clément Chigot" <chigot@adacore.com>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org
Subject: Re: [PATCH 0/5] block/vvfat: introduce "size" option
Date: Thu, 13 Nov 2025 09:41:19 +0100	[thread overview]
Message-ID: <aRWZr7tjdqKPlCjh@redhat.com> (raw)
In-Reply-To: <20251112123844.GA14264@redhat.com>

Am 12.11.2025 um 13:38 hat Richard W.M. Jones geschrieben:
> On Wed, Sep 03, 2025 at 09:57:16AM +0200, Clément Chigot wrote:
> > The main goal of this series is to introduce a new option "size" within
> > the vvfat backend (patch 5). It allows more control over SD cards' size.
> > The value for "Number of Heads" and "Sectors per track" are based on SD
> > specifications Part 2.
> > 
> > This series also includes minor patches:
> >  - patch 1 introduces another option to remove the Master Boot Record
> >    (this is mandatory for QNX)
> >  - patch 2-4 are minor improvements easing the introducing of "size"
> >    option
> > 
> > This was tested on with a aarch64-linux kernel taken from
> > functional/aarch64/test-virt and on aarch64-qnx over raspi4b with a
> > workaround, not included here (the SD bus must be associated to the EMMC2
> > port instead of through GPIOs).
> > 
> > Clément Chigot (5):
> >   vvfat: introduce no-mbr option
> >   vvfat: move fat_type check prior to size setup
> >   vvfat: add a define for SECTOR_SIZE
> >   vvfat: move size parameters within driver structure
> >   vvfat: add support for "size" options
> > 
> >  block/vvfat.c | 279 ++++++++++++++++++++++++++++++++++++++------------
> >  1 file changed, 213 insertions(+), 66 deletions(-)
> 
> (Thanks Markus for bringing this thread up)
> 
> I just wanted to say that a long time ago I wrote an nbdkit plugin
> that was intended as a more sane replacement for vfat.

What does it do differently from vvfat? For the read-only part, I
thought that vvfat wasn't too bad. Write support is where all the bugs
are hiding. But if you have good input, maybe vvfat could be improved.

> Since then several more nbdkit plugins have been added.  They support
> arbitrary sizes already.  The first one is the most direct replacement
> for vvfat (although it doesn't support writes to the backing
> directory, because that feature is insane).

The scenario we discussed here was explicitly read-write.

Kevin



  parent reply	other threads:[~2025-11-13  8:41 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
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 [this message]
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=aRWZr7tjdqKPlCjh@redhat.com \
    --to=kwolf@redhat.com \
    --cc=chigot@adacore.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=rjones@redhat.com \
    /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.