New PS2 FAT file-system driver wannabe

[606u]

http://606u.dir.bg/ps2/fat/ps2_fat-20040905.tgz is the current release of my FAT driver with writing support for PS2. It is not working as a file-system driver yet (that means, that you cannot use I/O calls, like open, read, write and close, yet), so it is too early to go party.

Task is separated on two major parts: a module handling USB mass storage in general and a FAT file-system driver (which is yet to be completed). Whether to separate partitioning support from file-system is yet undecided.

UMS module (read USB mass storage) handles communication with mass storage devices, includes LUN support and is not limited to a single device. It publishes a subscription point, where every module interested could subscribe for plug-in/plug-out events. There is also an interface to handle per-sector I/O (no `O' yet).

FAT file-system module will implement real file-system support and will implement standard I/O calls, but so far it would only ``dir'' the root directory of the connected USB device.

How to use: compile IOP modules and load them on the IOP (`make load' would do that via ps2client; I was unable to start it with naplink). When modules are running, upon plugging a USB mass storage device you'll get the contents of the root directories, for each FAT partition and for each LUN of the device, on the debug console.

Things whose are still on the whiteboard:
- must the driver automatically mount the plugged in device or that should be done after a manual call?
- if the driver would handle mounts automatically, how should the partitions be accessed? `fatfs1:', `fatfs2:',... or `C:', `D:',...?
- how to notify EE `clients' of plug-in/out events?

Feel invited to give it a try and to post your remarks and ideas.

Regards, b.

PS: Driver has been tested with a Lexar JumpDrive 128MB USB 2.0, USB 1.1 PQI 7in1 flash card reader with 16MB of build-in memory, with a compact-flash and multi-media cards plugged-in, and an external USB 2.0 HDD box with 20GB Quantum whatever.

[mharris]

if the driver would handle mounts automatically, how should the partitions be accessed? `fatfs1:', `fatfs2:',... or `C:', `D:',...?

I think the fatfs*: option would be much more in line with current driver semantics. IMHO the C:, D:, etc. would just be confusing -- unless you're planning on porting over an MS-DOS program (unlikely).

Will this be USB only, or do you plan on integrating with the HDD so a FAT formatted HDD could be used instead of the APA/PFS?

Just my 2c of course. Good work.

[ole]

must the driver automatically mount the plugged in device or that should be done after a manual call?

not neccessarily the driver, but some EE helper (automount) function would be handy.

if the driver would handle mounts automatically, how should the partitions be accessed? `fatfs1:', `fatfs2:',... or `C:', `D:',...?

imho it's better to stick to ps2 (numbering) notation.

how to notify EE `clients' of plug-in/out events?

I think that some simple reporting function that can be called from the EE shoud be fine.... but if it's really necessary then try EE rpc server.

[Drakonite]

- if the driver would handle mounts automatically, how should the partitions be accessed? `fatfs1:', `fatfs2:',... or `C:', `D:',...?

If you use 'C:', 'D:' ... I will destroy you. I will hunt you down, I will find you, and I will carve my name on your back with an ice pick.

Personally I'd recommend something like "UMS1:" or such nonesense.

On a semi-side note... Hmm... Quite interesting and incouraging to see there are three seperate usb mass storage drivers which all seem to be making large headway. :) On the subject of naming scheme, perhaps it would be beneficiary if all parties agreed on the same scheme?

[mrbrown]

Why would you call a FAT-formatted filesystem "UMS1:"? He's talking about partitions on the device, not the device itself.

Ideally you could mount "fatfsN:" to any "mass storage" device, whether it's USB or HDD, as mharris inquired. To do this I think you need to export the same interface that ps2hdd does to ps2fs. In that way you could even get ps2fs to work on USB mass storage devices.

[Drakonite]

Why would you call a FAT-formatted filesystem "UMS1:"? He's talking about partitions on the device, not the device itself.

Ideally you could mount "fatfsN:" to any "mass storage" device, whether it's USB or HDD, as mharris inquired. To do this I think you need to export the same interface that ps2hdd does to ps2fs. In that way you could even get ps2fs to work on USB mass storage devices.

Well, I said UMS (Usb Mass Storage) as I didn't think it would be intermingling as you are saying. If any fat formatted partitions on HDD and on USB are going to be intermingling then by all means use fatfs, but if thats the case keep some method of knowing which is HDD and which is usb...
Just my personal thoughts.

[mrbrown]

Yes, now that I think about it, The PFS driver doesn't care what it's being mounted to, because it uses IOCTLs and DEVCTLs off of the device name (which is "hdd0:") passed into mount(). So it should be feasible to create a FAT driver that doesn't care what it's being mounted to.

[606u]

Here is what I'm planning to do:

1st, I'm going to change UMS module a little; I'll add support for `ums:' file system, where dopen/dread/dclose calls would enumerate currently connected LUNs and open/read/write/lseek/lseek64/close calls would expose RAW I/O access. IOP-level notifications for plug-in and plug-out events would be preserved, but it would be nice to have those on EE-level, too. Most likely it will export LUN names and will be used like

Code: Select all

open ("ums:Quantum Fireball...", O_RDWR);

where `Quantum Fireball...' is the name returned by SCSI inquiry call (and you will "know" this name from dread call). When you have multiple devices with identical signatures, all devices but the first would have a trailing index, like `... #2'.

2nd, there is going to be a module handling IBM PC-style partitioning that could work on top of UMS module. It will export an interface, similar to the current APA module - dopen/dread/dclose would enumerate partitions and open/read/write/lseek/lseek64/close would allow RAW partition access. How to name that module and file-system is yet undecided. Will you be able to modify partition table is also yet undecided. Partition access would more likely be by index - something like

Code: Select all

open ("ums:Quantum Fireball.../0", O_RDWR);

meaning get 1st partition on `Quantum Fireball...' device/LUN and

Code: Select all

dopen ("ums:Quantum Fireball..."); 

would iterate among all partitions on the given LUN.

3rd, there is going to be a FAT file-system module working on top of partitioning one, something like PFS module and implementing most of the file-system calls (with some exceptions, like links and some rights, for example). That one will probably named `fatfs:'. One would be able to call mount and umount (I should take a more detailed look at how that shall be done).

I think this makes everything modular and flexible enough. Automount support is not currently planned, but there would be an autounmount support :-)

Phew... quite a story. How does it sound?

[MrSiir[S]]

Good job :-)

ps2client -h 192.168.2.3 execiop host:ums_fatfs.irx

Code: Select all

IOP cmd: 1 args
loadmodule: id 38, ret 0
ums_iop: device 1, LUN 0: "Generic  STORAGE DEVICE   1.25", USB 2.0, ready,
        127999KB total (255999 blocks of 512 bytes each).
ums_fatfs: connect_cb called for LUN c7600.
Partitions list:
        06: start_s 20 (32), length_s 3e7e0 (255968), RAW 127984KB
directory of /
d          0  2004-08-30 00:32:40  2004-08-30 00:32:42      8421 "TEST"
d          0  2004-09-03 18:56:52  2004-09-03 18:56:54       340 "XXX"
2 entries, 0 bytes total.
ums_fatfs: disconnect_cb called for LUN c7600.

[606u]

Altough I've almost gave up on this project, today I have some 10 hours of free time and I decided to push it a little. In http://606u.dir.bg/ps2/fat/ps2_fat-20050424.tgz you'll found:

- USB mass-storage driver, named "ums", which allows RAW file I/O to the external flash memory. Directory enumeration functions could be used to list all attached devices (LUNs are supported, too), and file I/O functions could be used to read/write RAW sectors.

sample use case:

Code: Select all

int fd = fileXioDopen ("ums:");
if &#40;!&#40;fd < 0&#41;&#41; &#123;
  iox_dirent_t dirent;
  int retval;
  while &#40;&#40;retval = fileXioDread &#40;fd, &dirent&#41;&#41; != 0&#41;  &#123;
    char buffer&#91;512&#93; = &#123; 0 &#125;;
    int fd2;
    printf &#40;"%8x %s\n", dirent.stat.size, dirent.name&#41;;
    sprintf &#40;buffer, "ums&#58;/%s", dirent.name&#41;;
    fd2 = fileXioOpen &#40;buffer, O_RDWR, 0&#41;;
    if &#40;!&#40;fd2 < 0&#41;&#41; &#123;
      // trash your flash &#58;-&#41;
      fileXioClose &#40;fd2&#41;;
    &#125;
  &#125;
fileXioDclose &#40;fd&#41;;

Theoretically, it is possible to hack pfs driver to work against this one (there are "hdd" checks inside and perhaps more).

- FAT file-system driver, named "fatfs". To use it, you should first mount a particular FAT partition. Currently partition handling code and FAT code are integrated in a single driver, hence you cannot use FAT file-system inside APA partition (and I don't see a point of doing such thing).

simple use case:

Code: Select all

// imagine device "Generic STORAGE 1.05" has been plugged in
// mount first FAT partition
if &#40;!&#40;fileXioMount &#40;"fatfs1&#58;", "ums&#58;Generic STORAGE 1.05/1", 0&#41; < 0&#41; &#123;
  // imagine a file 1.TXT exists there
  int fd = fileXioOpen &#40;"fatfs1&#58;/1.TXT", O_RDONLY&#41;;
  if &#40;!&#40;fd < 0&#41;&#41; &#123;
    // ...
    fileXioClose &#40;fd&#41;;
  &#125;
  fileXioUmount &#40;"fatfs1&#58;"&#41;;
&#125;

Once again, theoretically, it is possible to make a simple driver for RAW sector access and to plug a FAT drive in the HDD bay to use it with this driver.

- Client can subscribe for plug/unplug events, but currently that only works on IOP. I've read somewhere, that events can be send to EE by using interrupts, so any pointers where to find such sources are welcome.

- There is a quick-and-dirty EE sample application included that attempts to read a file from the first FAT partition from all attached devices each few seconds.

You're welcome to give it a try, but don't expect too much :-)

Code: Select all

cd ps2_fat/iop
make
cd ../ee/test
make
make load

[606u]

There is a new release with only a handful of features missing: long file names, few APIs, decent speed and better reliability :-)

Let's hope they'll come in a week or so.

[J.F.]

Are those what it has, or what it's missing? :)

[606u]

Are those what it has, or what it's missing? :)

Missing :-)