If you want to avoid any installation on the Windows PC, you need to do
or find a virtualization that simulates an FAT formatted device.

-Michael

I'm not aware of such a virtualization, maybe you need to do it
yourself.  But FAT is not that complicated, so read-only seems quite
doable.

That might be possible and would allow for using the g_file software you
mentioned to hook same to the USB interface, but I feel that this is
much more complex than handling the appropriate USB read block yourself
(i.e. modifying the g_file software ). (But I might be wrong.)

-Michael

That's exactly what I want to do. Any idea where to start looking for
such a virtualization - and yes, read only is all I need

As I have not found one yet I'm looking into the possibility of
implementing it myself.
I'm just not sure what the right approach would be. My idea would be
to implement a block device driver.

Well I looked into it and that might be the final solution, but if I
write an own device driver
I only have to worry of the device driver not working.
When modifying g_file I would need to worry about breaking the UBS
part ...

I suppose g_file interfaces the block device it is runtime-configured to
use at just a few places. You would replace "write" block-device
access(es) by an error condition and the "read" the block-device
access(es) by a function call to the function you will create. Same gets
a sector number and count and is supposed to fill a buffer with a
sequence of bytes. This can't harm the USB functionality.
Yes, that's exactly how they do it - read raw blocks from a file or a

Of course I would be interested to see the source code once you get it
going
Well, lets see if I ever get that far ^^

-Michael

Well it sounds easy as you write it, but creating a fat in the
background - at least some caching for the most important structures
is required - and give the right block - created on the fly - back
when asked for the block number seems not an easy task to me.

So I plan to first create a few simple things as user apps:
- simple static fat which can be mounted using a loop device

- simple app read a directory structure, convert it into static fat,
mountable using loop

Now write a simple block device driver (module) which builds upppon
simple app 2
challenges here might be:
- access directory using vfs access inside the kernel instead of user
space
- get the blocks dynamicly created
This block device should be mountable as fat

If that is done I only need to load g_file_storage with the device
- sounds easy ... right ^^

Still ranting on...
Keep doing it - been a bit bussy.

If the PC requests a sector (or multiple) from the file area (sector =
file area start sector + cluster * (clustersize / sectorsize) ) you
calculate the cluster no, and thus the file in question and the relative
location of the sector. So you can open the file and read the
appropriate bytes and provide them via USB.

BTW.: Where did you fined the g_file code ? I'd like to take a look at
it but googeling did not show a location.

-Michael

Yep. that's the plan, but you have to create the directory entries for
it.
And they might change - using an arbitrary directory in the Linux file
system as root of the fat.

Of course, using a directory with files only for starters would be a
sensible approach.

Its part of the Linux kernel
driver/usb/gadget/file_storage.c