Transitioning fat:/ to sd:/ on Wii

Support for the GBA/DS/Gamecube/Wii media card library
Post Reply

What is your prefered way of transitioning device names

Just use fat:/ instead of sd:/ to refer to the built-in SD card slot
11
17%
Create an alias in devoptab that points fat:/ to sd:/
12
19%
Automatically modify argv[0] to change the leading fat: to sd:
4
6%
Have the loader determine if the application is old or new and supply it with the expected path
7
11%
Force everyone to use sd:/
29
46%
 
Total votes: 63

chishm
Posts: 3
Joined: Sat Oct 27, 2007 9:39 am

Transitioning fat:/ to sd:/ on Wii

Post by chishm » Wed Dec 24, 2008 2:46 am

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
Posts: 5
Joined: Wed Feb 27, 2008 1:44 pm

Re: Transitioning fat:/ to sd:/ on Wii

Post by bushing » Wed Dec 24, 2008 6:00 am

chishm wrote: 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
Posts: 3
Joined: Sat Oct 27, 2007 9:39 am

Re: Transitioning fat:/ to sd:/ on Wii

Post by chishm » Wed Dec 24, 2008 7:19 am

bushing wrote: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.
bushing wrote:Do we know of any specific apps that currently do that?
I believe Dhewg uses this in ScummVM.
bushing wrote: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
Posts: 5
Joined: Wed Feb 27, 2008 1:44 pm

Re: Transitioning fat:/ to sd:/ on Wii

Post by bushing » Wed Dec 24, 2008 8:06 am

chishm wrote:
bushing wrote: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.
bushing wrote:Do we know of any specific apps that currently do that?
I believe Dhewg uses this in ScummVM.
bushing wrote: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
Posts: 3
Joined: Sat Oct 27, 2007 9:39 am

Re: Transitioning fat:/ to sd:/ on Wii

Post by chishm » Wed Dec 24, 2008 9:26 am

bushing wrote: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
Site Admin
Posts: 1385
Joined: Tue Aug 09, 2005 3:21 am
Location: UK
Contact:

Re: Transitioning fat:/ to sd:/ on Wii

Post by WinterMute » Thu Dec 25, 2008 3:10 am

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.
Help keep devkitPro toolchains free, Donate today

devkitPro IRC support
Personal Blog

bushing
Posts: 5
Joined: Wed Feb 27, 2008 1:44 pm

Re: Transitioning fat:/ to sd:/ on Wii

Post by bushing » Fri Dec 26, 2008 5:23 am

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.

Post Reply

Who is online

Users browsing this forum: No registered users and 0 guests