 |
forums.ps2dev.org Homebrew PS2, PSP & PS3 Development Discussions
|
| View previous topic :: View next topic |
| Author |
Message |
dlanor
Joined: 28 Oct 2004 Posts: 269 Location: Stockholm, Sweden
|
Posted: Fri Apr 22, 2005 11:27 am Post subject: |
|
|
| ooPo wrote: | | Fix the problem, don't work around it on a one-by-one basis. That's how code becomes unmanageable and overweight. |
Indeed, and instead of simplifying things that might even create new complications, if different one-on-one solutions conflict with each other.
(eg: unrelated partition types identified by the same "PP." prefix.)
However, fixing "the problem" as you say (and I agree with) demands that this problem be clearly defined. Hopefully this discussion will do exactly that. (Not through my own post of course, but eventually.)
I'm not well enough informed on the low-level details to contribute any solution. But it seems clear (both from those delays, and from earlier posts about HDD access functions) that current methods to access just a single partition is done in a way that wastes time by reading info *from* several partitions, rather than just reading info from the partition list to identify those partitions. Surely that must be the hub of the problem, regardless of the 'depth' of the routines that contain the code doing it.
Obviously, the existing API must remain unchanged, to avoid breaking compatibility with all existing HDD software, but that should be no hindrance to adding a new lib (or new functions to the old :) ) specifically to allow more efficient HDD access. And naturally this should deal the same way with ALL partition types, with no special treatment for any.
Best regards: dlanor
Last edited by dlanor on Sat Apr 23, 2005 12:48 am; edited 1 time in total |
|
| Back to top |
|
 |
KaylaKaze
Joined: 05 May 2004 Posts: 75 Location: NC, USA
|
Posted: Fri Apr 22, 2005 10:23 pm Post subject: |
|
|
| ooPo wrote: | Writing a couple new functions won't fix it. Take a look...
| Code: | | rv = fileXioDread(hddFd, &dirEnt); |
That shows the problem is not here, but elsewhere. Either in fileXio or in the function *it* calls later on to access the hdd device.
|
My guess is maybe opening a protected partition, then failing, takes longer than we'd like, since the following code doesn't look like it should take long.
| Code: | // Calculate filesystem size
partitionFd = fileXioOpen(hddFs[count].filename, O_RDONLY, 0);
// If we failed to open the partition, then a password is probably set
// (usually this means we have tried to access a game partition). We
// dont want to return un-accessible game partitions in the filesystem list..
if(partitionFd < 0)
{
rv = fileXioDread(hddFd, &dirEnt);
continue;
}
|
Since this code should skip protected partitions like the filter I originally suggested and there are no other HD calls between here and the the patch I implemented, the fileXioOpen call seems to be the culprit. I can't make heads nor tails of the fileXioOpen function so I can't be of any more assistance on that. |
|
| Back to top |
|
 |
weltall
Joined: 20 Feb 2004 Posts: 310
|
Posted: Sat Apr 23, 2005 4:21 am Post subject: |
|
|
but "censuring" partitions is not the best thing because if you want to do a partition manager or similar you can't do it correctly if it shows only some partitions...
anyway i think that there is bigger issues than performance issue in libhdd for example >4gb partitions not working well (pfs partitions) |
|
| Back to top |
|
 |
|
|
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 vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|