Talk:/dev/fsa

I'm planning on finishing up this page and adding in all of the FS/FSA commands. I've already mapped most of them to their Ioctl/Ioctlv commands (51 commands so far, including 2 that I have yet to figure out their function but know they are valid commands at least in Debug mode) Question is, which format to use. The /dev/mcp format doesn't explain the parameters for the functions like /dev/crypto does, and these have much more detail. I'm thinking of either going to a new format, or putting this all on a different page more aimed at the functions than the ioctals.

  Function Name        Command  Ioctl	Ioctlv	  Async Version	  FSA* Function
  FSMount	         0x1	  N	  Y	      Y	              Y

  FSStatus FSMount( FSClient*client, FSCmdBlock*block, FSMountSource *source, char*target, u32 bytes, FSRetFlag errHandling );
  Mount a volume.
  Results -> FS_STATUS_OK               = Successfully completed.
             FS_STATUS_CANCELED         = The command was canceled.
             FS_STATUS_NOT_FOUND        = Target not found.
             FS_STATUS_EXISTS           = Specified device file is already mounted, or specified target path is in use with another volume.
             FS_STATUS_UNSUPPORTED_CMD  = Target has been formatted to unsupported file system.
             FS_STATUS_PERMISSION_ERROR = The caller does not have correct access permission.
             FS_STATUS_MEDIA_ERROR      = Media is in some inaccessible condition.
  Parameters:
   client      = Pointer to the client buffer.
   block       = Command block.
   source      = Pointer of mount source.
   target      = Buffer for target mount point path.
   bytes       = Length of the target. This must be greater than or equal to FS_MAX_MOUNTPATH_SIZE.
   errHandling = Auto error handling flag. Only indicated errors are returned. (See -> responses above)

Or just parse it down to minimum info -or- maybe this should all go an a different page... Datalogger (talk) 10:52, 12 May 2016 (CEST)

That format looks nice! For what it's worth, I would just go for replacing the current list format with an elaborate function documentation like this for each list entry. The raw list on its own isn't particularly useful for anything unless one needs to work with the raw ioctl interfaces, which hopefully will be obsolete when someone writes a library for this stuff. Neobrain (talk) 12:07, 22 May 2016 (CEST)

I'm thinking I'll go ahead and map all of the Ioctl commands to their type in a simple table (ioctl/ioctlv/ioctlAsync/ioctlvAsync), then below that, give a detailed explanation for the parameters and return values for each one.

My reason is, a quick table makes it easy to see if there's an Async you can call from PPC using an IPC. Datalogger (talk) 12:21, 23 May 2016 (CEST)

I feel like I'm missing something here; all IOS calls from the PPC are async by design, and IPC calls within IOS can be either - they're not restricted to one mode or the other. Tueidj (talk) 12:45, 23 May 2016 (CEST)