USBMSC and loop device in ROMFS (with patches)

[Fabio D'Urso [e-mail] [nuttx]]

Hello,

I am trying to expose a static FAT disk image (stored in ROMFS) to a PC
as a USB disk.

I have found what seems to be a copy-and-paste issue in
drivers/loop/losetup.c: it tries to open the image in RW mode first and
then RW again for the second attempt, despite the comment saying that
the second attempt is in RO mode. As a result, ROMFS files cannot be
used with losetup ("losetup: ioctl failed: EACCES").

With the attached fix (nuttx-losetup.patch), I can successfully run:

 losetup -r /dev/loop0 /etc/usb-disk.img
 msconn

and Linux sees the USB disk:

 scsi host7: usb-storage 3-1:1.0
 scsi 7:0:0:0: Direct-Access     NuttX    Mass Storage     0101 PQ: 0
ANSI: 2
 sd 7:0:0:0: Attached scsi generic sg4 type 0
 sd 7:0:0:0: [sdd] 100 512-byte logical blocks: (51.2 kB/50.0 KiB)
 sd 7:0:0:0: [sdd] Write Protect is off
 sd 7:0:0:0: [sdd] Mode Sense: 0f 00 00 00
 sd 7:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
  sdd:
 sd 7:0:0:0: [sdd] Attached SCSI disk

However, the disk is detected as writable (and I/O errors occur if you
try to edit its contents). I noticed that NuttX's usbmsc_bindlun
(drivers/usbdev/usbmsc.c) is smart and tries to guess whether the disk
should be presented as writable or not, according to the presence of the
write() method in the storage device's file operations table.
Unfortunately, this heuristic fails in this case, because the loop
device driver does have write() support for the general case of RW loop
devices.

I have solved this problem by adding Kconfig parameters to make it
possible to have msconn force the readonly flag. I am attaching this
second patch (apps-kconfig.patch) as well. With both patches applied and
the new Kconfig option set (it is unset by default - same behavior as
before), I have tested that everything works as intended:

 sd 7:0:0:0: [sdd] Write Protect is on
 sd 7:0:0:0: [sdd] Mode Sense: 0f 00 80 00
 sd 7:0:0:0: [sdd] Write cache: disabled, read cache: enabled, doesn't
support DPO or FUA

Best regards,

Fabio D'Urso

[[e-mail] [nuttx]]

Thanks, Fabio,


Those all look like good changes and I have committed and pushed the changes. I have never heard of anyone using a read-only FAT file system so it is not surprising that there were some issues there.


When the MMC/SD block driver is used, it can sense the write protect setting of the SD card in most cases. And from write only file systems, you can detect that is write only because the write method is NULL. So I think that on option might add some runtime way to determine if the file system is writable. But that would be more complex.


I think your solution is reasonable.


FAT may try to write things like creation times and access times but, apparently, it handles those write failures correctly because you see no issues.


That copy paste error is typical of a class of error I make: I copy a block of code with intention to modify it but get distracted with other issues and forget to do the modification. Thanks for catching that. That is probably the first time that code has executed.


Greg