On Thu, Nov 13, 2025 at 09:41:19AM +0100, Kevin Wolf wrote: > 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.
There are a bunch of reasons why you'd want the less common drivers to be running outside qemu, and not be a part of qemu at all: - It's more secure, not just because it's running in a separate process, but because you can confine the process differently (eg with SELinux). - The command line is far simpler and more intuitive compared to, say, q-s-d. - There's a simple nbd:// URI scheme for these endpoints, and a whole suite of tools for querying, copying and modifying these NBD endpoints, like nbdinfo, nbdcopy, nbddump, nbdsh, (and more). This is all based on public standards and interoperability tests, with clients in several programming languages. - You can consume NBD elsewhere than just from qemu, including over the network. - Huge array of weird and ugly plugins that wouldn't be desirable or even possible in qemu (because they are proprietary like VDDK, or written in Python or other scripting languages like our AWS support). Also a much wider choice of programming languages - vvfat might be more tractable if written in a scripting language. - A number of out of tree plugins that companies develop, which we enable because we have hard ABI guarantees, but qemu does not (and I understand why qemu does not do this, and those are good reasons). > > 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. Indeed, nbdkit-floppy-plugin doesn't support writes to the backing filesystem right now. Some others I listed in the original email do support writes, and you can add a COW layer on top of any of them (which is not the same thing of course). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html
