I'm using an embedded linux system and want to make a part of the file
system accessible from a Windows System using USB mass storage.

I know about the usb gadget driver g_file_store. This however only
works with devices or files.
As I want to be able to access the mass storage from Windows the
device/partiton or file must be formated in fat.

Is there a solution out there which lets me map a part of the linux fs
(tempfs, jffs2, fuse) as a fat formated block device or file?

What you can't do is modify the contents of that file while it's
mounted on another machine as a USB mass storage device - even if it's
mounted read only, the remote machine isn't expecting the contents of
the disk to go and change unexpectedly, as that could break any
caching of data or metadata by the remote system.

Create a fat filesystem inside an image file on your linux file
system.  Point gadget at this storage space, and it will represent it
to the USB host as a mass storage device containing a fat filesystem.
Good idea, only problem is, that the file system I want to provide is

What you can't do is modify the contents of that file while it's
mounted on another machine as a USB mass storage device - even if it's
mounted read only, the remote machine isn't expecting the contents of
the disk to go and change unexpectedly, as that could break any
caching of data or metadata by the remote system.
I'm clear on that.

What you can't do is modify the contents of that file while it's
mounted on another machine as a USB mass storage device - even if it's
mounted read only, the remote machine isn't expecting the contents of
the disk to go and change unexpectedly, as that could break any
caching of data or metadata by the remote system.

That of course is very true and has not been discussed yet.

If installing something propriety on the Windows system is necessary,
maybe using "serial via USB" might be the easiest way to go.

-Michael

No, it must be simple mass storage.

On 18 Jul., 19:17, cs_post... at (no spam) hotmail.com wrote:> Create a fat filesystem inside an image file on your linux file
system. Point gadget at this storage space, and it will represent it
to the USB host as a mass storage device containing a fat filesystem.

Good idea, only problem is, that the file system I want to provide is
much bigger than my flash storage or my memory.
So statically creating the file system is out of the question.

On 20 Jul., 08:16, Dan Danillo <dandani... at (no spam) ymail.com> wrote:

Imagine a mounted SD-Card combined with data from the embedded system.
Representing multiple partitions or devices are no option either.

On Jul 20, 2:16 am, Dan Danillo <dandani... at (no spam) ymail.com> wrote:

On 18 Jul., 19:17, cs_post... at (no spam) hotmail.com wrote:> Create a fat filesystem inside an image file on your linux file
system.  Point gadget at this storage space, and it will represent it
to the USB host as a mass storage device containing a fat filesystem.

Good idea, only problem is, that the file system I want to provide is
much bigger than my flash storage or my memory.
So statically creating the file system is out of the question.

Ah, okay, point gadget at /dev/zero then...

Seriously, where were you planning to get the data from?

Wherever the data is coming form, if you can represent that as a block
device, you should be able to point gadget at it.

Dan Danillo wrote:

No, it must be simple mass storage.

o some means needs to be introduced that the files don't change while a
connection is established.

-Michael

On Jul 20, 2:19 am, Dan Danillo <dandani... at (no spam) ymail.com> wrote:

On 20 Jul., 08:16, Dan Danillo <dandani... at (no spam) ymail.com> wrote:

Imagine a mounted SD-Card combined with data from the embedded system.
Representing multiple partitions or devices are no option either.

How about some foolery in the SD drivers to make a local image file
containing the local data overlay some clusters on the SD-card, and
put a dummy file in it's FAT pointing to them?

Actually, it's probably better to write a wrapper translation driver
the wraps the SD block device and does the substitution.  But i might
be tempted to try it by modifying the SD driver first...

I think the big problem would be if somebody else wrote to the card
and moved your dummy file - actually, that could be handled just by
finding it and telling the translator where it is.  It's if they made
it non-contiguous that you'd be in pain.

How about some foolery in the SD drivers to make a local image file
containing the local data overlay some clusters on the SD-card, and
put a dummy file in it's FAT pointing to them?
Actually, it's probably better to write a wrapper translation driver

Modify an existing driver - don't like that idea.

The data on the sd-card wont change, the data on the fs might change.
If I can notice that I can disconnect unload g_file store and load it
again.