View unanswered posts | View active topics It is currently Thu Dec 14, 2017 8:54 am



Reply to topic  [ 7 posts ] 
 Transitioning fat:/ to sd:/ on Wii 

What is your prefered way of transitioning device names
Just use fat:/ instead of sd:/ to refer to the built-in SD card slot 19%  19%  [ 10 ]
Create an alias in devoptab that points fat:/ to sd:/ 19%  19%  [ 10 ]
Automatically modify argv[0] to change the leading fat: to sd: 6%  6%  [ 3 ]
Have the loader determine if the application is old or new and supply it with the expected path 13%  13%  [ 7 ]
Force everyone to use sd:/ 44%  44%  [ 24 ]
Total votes : 54

 Transitioning fat:/ to sd:/ on Wii 
Author Message

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


Wed Dec 24, 2008 2:46 am
Profile

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


Wed Dec 24, 2008 6:00 am
Profile

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


Wed Dec 24, 2008 7:19 am
Profile

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


Wed Dec 24, 2008 8:06 am
Profile

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


Wed Dec 24, 2008 9:26 am
Profile
Site Admin

Joined: Tue Aug 09, 2005 3:21 am
Posts: 1210
Location: UK
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


Thu Dec 25, 2008 3:10 am
Profile ICQ WWW

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


Fri Dec 26, 2008 5:23 am
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 7 posts ] 

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.
Get devkitPro at SourceForge.net. Fast, secure and Free Open Source software downloads