Am 13.11.2025 um 10:13 hat Richard W.M. Jones geschrieben: > 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).
Ok, so nothing in particular that the nbdkit floppy plugin does better than vvfat that could be worth looking at? I can kind of get the argument that running things in separate processes is always safer, though in the typical vvfat use case your VM is trusted, so it doesn't really matter much. So I wouldn't argue using QSD for this case either, even though it would provide the same isolation. For human use, the simplicity of use for built-in vvfat is hard to beat. (Ignoring all the other points that are just generic nbdkit advertising with no relevance for the vvfat use case.) > > > 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). >From that list, it seems to be only tmpdisk, which obviously isn't well suited to be used to copy files between host and guest? Kevin
