Transitioning fat:/ to sd:/ on Wii

[chishm]

As you've probably noticed, the newest libfat uses sd:/ and usb:/ instead of fat[0-9]: on the Wii. This had the unintended side-effect of breaking the current working directory passed in via argv[0] from loaders. There are a few strategies to fix this, but none of them are perfect, so I need some opinions.

Option 1: Just use fat:/ instead of sd:/ to refer to the built-in SD card slot.
Advantage: Everything stays as it was, so nothing breaks.
Disadvantage: No more friendly device name for the SD slot, it's permanently called the unintuitive "fat".

Option 2: Create an alias in devoptab that points fat:/ to sd:/.
Advantage: The SD slot can still be refered to as fat:/, but also as sd:/.
Disadvantage: Enumerating devoptab no longer provides a unique list of devices.

Option 3: Automatically modify argv[0] to change the leading fat: to sd:.
Advantage: We keep the friendly device name and devoptab behaves as expected.
Disadvantage: Hacky string manipulation, the application can't use fat:/ in any paths.

Option 4: Have the loader determine if the application is old or new and supply it with the expected path.
Advantage: No hacks to libfat necessary.
Disadvantage: No know way of determining the library version.

Option 5: Force everyone to use sd:/ (the current situation).
Advantage: Instant transition to friendly device names.
Disadvantage: Shit breaks.

If there's another option don't be afraid to suggest it.

[bushing]

Option 2: Create an alias in devoptab that points fat:/ to sd:/.
Advantage: The SD slot can still be refered to as fat:/, but also as sd:/.
Disadvantage: Enumerating devoptab no longer provides a unique list of devices.

How valuable is that operation (enumerating devoptab to produce a unique list of devices)?
Do we know of any specific apps that currently do that? What actual effects will there be if there is an "alias" in the table?

[chishm]

How valuable is that operation (enumerating devoptab to produce a unique list of devices)?

It allows you to retrieve a list of all mounted devices, which is useful for browsing for files.

Do we know of any specific apps that currently do that?

I believe Dhewg uses this in ScummVM.

What actual effects will there be if there is an "alias" in the table?

The same device will show up twice, under two different names. On the surface it will appear to be two separate devices, but in reality they will share all the same underlying data structures. The biggest problem will be caused when unmounting one of the devices unexpectedly affects the other.

[bushing]

How valuable is that operation (enumerating devoptab to produce a unique list of devices)?

It allows you to retrieve a list of all mounted devices, which is useful for browsing for files.

Do we know of any specific apps that currently do that?

I believe Dhewg uses this in ScummVM.

What actual effects will there be if there is an "alias" in the table?

The same device will show up twice, under two different names. On the surface it will appear to be two separate devices, but in reality they will share all the same underlying data structures. The biggest problem will be caused when unmounting one of the devices unexpectedly affects the other.

Well, I expect to actually meet dhewg IRL next week, so if he's the only one...

Is the problem here in the interface between the loader and the application, or within the application? If it's the latter, then I say we stick with option 5 -- the only shit that will break will be apps that are recompiled, and hopefully those doing the recompilation will notice that during testing and fix it.

Not that this is a great justification, but we have precedent for breaking apps left and right with loader / interface changes (e.g. HBC v1.0 vs most ELF executables), so we might as well just get it over with, eh?

[chishm]

Is the problem here in the interface between the loader and the application, or within the application? If it's the latter, then I say we stick with option 5 -- the only shit that will break will be apps that are recompiled, and hopefully those doing the recompilation will notice that during testing and fix it.

It will break the interface between the loader and the application. If a loader compiled against the old libfat loads an app compiled against the newer libfat, it will pass a fat:/ prefixed path to an app that doesn't know of any fat: device. The same happens in the reverse situation, passing sd:/ to an app that expects fat:/. Once everything is compiled against the new libfat it should be fine, provided the apps don't explicitly use a fat:/ path anywhere else.

[WinterMute]

The best course of action has to be option 5. Loaders can be updated and recompiled, as can applications with libfat dependency.

devkitPro does have a tradition of keeping legacy code to an absolute minimum, especially where maintaining old APIs has the potential to cause problems with new code.

[bushing]

Yeah, I think we're in agreement here. Interface breakage sucks, but the community is small enough that we can generally get popular programs (apps or loaders) rebuilt pretty quickly to cope.