gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > devoptab_t

#115182 - SukkoPera - Sat Jan 13, 2007 3:58 pm

I'm trying to make libfat and my libblockdev live together in the same application. Although I can't fully understand the whole device managemente in newlib.

This is how _I THINK_ it works:
- I register both both libfat and libblockdev using AddDevice(). I guess I should check its return value, so I assumed that anything >= 0 is OK, while < 0 means an error. This way it seems that both libraries get registered correctly.
- I don't set either one as the "default device". I don't know exactly what a "default device" is. I guess it's the one used when dealing with paths that don't start either with "fat:" or "raw:" (which are the names declared in the first element of devoptab_t of the two libraries). Therefore I guess I have to use explicit pathnames when opening a file.
- Problem is that all file operations are always performed with the library I register last, independently of the path name. Also, FindDevice() returns -1 for the previously registered library.

Is this normal (maybe I cannot register more than one device at the same time, but then why the need of a name and of a default device?) or am I wrong somewhere?
_________________
Nintendo DS Lite (White) + Supercard Lite + R4 + Sandisk 1 GB MicroSD
Sony PSP + Firmware 3.03 OE-A2

#115185 - wintermute - Sat Jan 13, 2007 4:07 pm

Please supply a testcase illustrating the problem, preferably to the devkitARM mailing list.

Reports like this are always best accompanied with source code.

Note also: a testcase means a small example. In this case two devices with just the open call implemented should be sufficient - i.e. just printing the name of the device on open.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#115190 - SukkoPera - Sat Jan 13, 2007 4:48 pm

OK, talking on IRC with wintermute, we found out there's a bug in a newlib patch:

Code:
//---------------------------------------------------------------------------------
int AddDevice( const devoptab_t* device) {
//---------------------------------------------------------------------------------
 
        int devnum;
 
        for ( devnum = 3;devnum <STD_MAX; devnum++ ) {
 
                if ( (strcmp(devoptab_list[devnum]->name, device->name) &&
                                        strlen(devoptab_list[devnum]->name) == strlen(device->name) ) ||
                                       !strcmp(devoptab_list[devnum]->name, "stdnull")
                         )
                         break;
        }
 
        if ( devnum == STD_MAX ) {
                devnum = -1;
        } else {
                devoptab_list[devnum] = device;
        }
        return devnum;
}


Example case:
- First I AddDevice() the "fat" device.
- Then I AddDevice() the "raw" device. As of now, the first strcmp() is != 0, and the strlen()s are the same, which means that the "fat" entry will be overwritten.

This is cause by a missing "!" in the first strcmp. Also, the bug can be worked around by making sure all the registered devices have a different-length name (which invalidates the first part of the if through the strlen() condition).
_________________
Nintendo DS Lite (White) + Supercard Lite + R4 + Sandisk 1 GB MicroSD
Sony PSP + Firmware 3.03 OE-A2

#115192 - wintermute - Sat Jan 13, 2007 4:51 pm

Nice catch.

This will be applied in r20 which gets ever closer. I'm aiming for the end of January but hopefully a little sooner.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#115197 - simonjhall - Sat Jan 13, 2007 5:41 pm

I don't know really anything about this newlib lark (why is it called newlib anyway?) but from what I understand, this sort of stuff allows you to use things like fprintf without any extra (DS-specific) code - right?
If so, would this be the interface to use if I were to write a wifi DS<->PC filesystem?
_________________
Big thanks to everyone who donated for Quake2

#115265 - wintermute - Sun Jan 14, 2007 8:15 am

newlib is the C runtime library used by devkitARM, it's intended to be a "lighter" version of glibc for embedded systems, thus (new) C runtime (lib)rary.

The interface we're talking about here is the pseudo device API I've written for it which allows the low level stdio support functions to be hooked for platform specific code.

It will allow you to use stdio functions as intended on platforms where there is no OS support. I wouldn't go quite as far as saying "without any extra (DS-specific) code" since the code implementing the low level functions is quite platform specific. Initialising the device driver is currently pretty devkitARM specific but I intend to port this into devkitPPC at some point in the near future.

Quote:

If so, would this be the interface to use if I were to write a wifi DS<->PC filesystem?


Yes, it's absolutely ideal for this purpose.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog