Back to HEN-3.0.3

A

Algol

Member
Hello tous les DEVs.

Je suis très embêté car je suppose que le HEN-3.1.1 bloque le démarrage normal de certains jeux PS2-Classics.
Je possède 3 consoles non compatible au CFW de modèle CECH-3004, 4004 et 4204C sous le HFW-4.88.1. J'ai passé, sans réfléchir aux conséquences possibles, mon HEN-3.0.3 en HEN-3.1.1 sur ces 3 machines en même temps.
Quelques jeux au format PS2-Classics dont "Bomberman Kart", "Gran Turismo 4", "BurnOut 1" et aussi "BurnOut 2" (tous ces jeux sont des PAL Euro) ne démarrent pas, c'est le "Tetris" qui est lancé à leur place.
Je précise qu'auparavant, ces jeux étaient déjà dans ces consoles et ils fonctionnaient sans erreur de très longues heures. Je n'ai aucune erreur sur les 3 DD (contrôle fait) et il y a de nombreux jeux installés dans le dossier PS2ISO de chacune.

Après quelques discussions avec @aldostools , j'en suis contraint de supposer que c'est la Mise-à-jour 3.1.1 du HEN qui provoque ces changements qui n'existaient pas en HEN-3.0.3 encore présent il y peu de temps sur ces 3 machines.

Question 1 : Un membre a-t-il ces soucis avec ces jeux, lui est-il possible de le signaler SVP ???
Question 2 : Est-il possible de revenir sur le HEN-3.0.3 sans devoir formater les DD internes ???


In English via G-Trad :

Hello all DEVs.

I am very annoyed because I suppose that the HEN-3.1.1 blocks the normal start of certain PS2-Classics games.
I have 3 consoles not compatible with the CFW of CECH-3004, 4004 and 4204C model under the HFW-4.88.1. I passed, without thinking about the possible consequences, my HEN-3.0.3 in HEN-3.1.1 On these 3 machines at the same time.
Some games in Ps2-Classics format including "Bomberman Kart", "Gran Turismo 4", "Burnout 1" and also "Burnout 2" (all these games are PAL Euro) do not start, it is the "Tetris" which is launched in their place.
I specify that before, these games were already in these consoles and they worked without error very long hours. I have no error on the 3 DDs (control made) and there are many games installed in the PS2ISO file of each.

After some discussions with @aldostools, I am forced to suppose that it is the update 3.1.1 of the HEN which causes these changes which did not exist in HEN-3.0.3 Still present there little time on these 3 machines.

Question 1: Does a member have these concerns with these games, is it possible to report it please ???
Question 2: Is it possible to return to the HEN-3.0.3 without having to format the internal DDs ???

Full thanks in advance.
 
2) you do not have to format. :)

i would reinstall hfw 4.88 and then hen 3.0.3. after installing hen, install my "no auto-uodate" mod 4.88 version from HERE (that way 3.1.1 will not come back if you connect to internet).
 
It would help if someone would post debug HEN socat output at the time you trigger the issue, it would avoid us having to reproduce the problem to do it. lol
There could be answers right there about the cause, and if there's nothing obvious, it will have to be investigated.
 
bguerville said:
So the issue is not related specifically to a bug in HEN 3.1.1 if I understood correctly and this matter is resolved?
Click to expand...
Yep, reinstalling the PS2 Launcher while a game was still mounted, was causing Algols disc images get overwritten due to the symlink. Not sure if there is any solution to an issue like this, maybe just letting people know it can happen is the solution.

Edit: Maybe there is a better way, like what if exiting a PS2 ISO game also caused it to be ejected/unmounted. It would not totally solve this but would probably reduce it a lot. I'm sure some of you guys could come up with something better. Ideally what is required is a one way symlink if there is any way to do that idk?
 
Last edited:
DeViL303 said:
Yep, reinstalling the PS2 Launcher while a game was still mounted, was causing Algols disc images get overwritten due to the symlink. Not sure if there is any solution to an issue like this, maybe just letting people know it can happen is the solution.

Edit: Maybe there is a better way, like what if exiting a PS2 ISO game also caused it to be ejected/unmounted. It would not totally solve this but would probably reduce it a lot. I'm sure some of you guys could come up with something better. Ideally what is required is a one way symlink if there is any way to do that idk?
Click to expand...
The solution is simple, but the user must be aware: delete PS2 Launcher before reinstall it. Or simply install it once.

The other solutions are inconvenient:
- mount the game copying the file instead of link it. It takes around 1 minute to copy a large game.
- unlink the game through the unmount command. It reduces the chance, but not solves the issue if the launcher is reinstalled with the game mounted. I can implement it if it is requested.
 
@aldostools @bucanero @Zar @LuanTeles and ps3 devs in general.

I think there is a conceptual issue in map_path that existed before that's still there in my rewrite.

Let's imagine you have a file

/dev_hdd0/folder1/file1.txt

Now say you have 3 mappings


/dev_hdd0/
to
/dev_flash


/dev_hdd0/folder1
to
/dev_flash/folder2


/dev_hdd0/folder1/file1.txt
to
/dev_flash/folder3/file1.txt



The 3 mappings could apply to our file1.txt.
Which exactly should the system use?
One could say that the 3rd mapping should probably be applied because it names the file exactly.
But then another could say well it should be the first mapping that wins because it's the one at the lowest level in the tree directory.

Both could be right, it just depends what kind of mapping priority order one wishes to apply.

So we need to choose, we cannot have everything, keeping in mind of course the legacy behaviour to preserve.

And currently, the first one used is the first one found in the mappings linked list therefore it would depend on the order in which they were added.
One could say it's not such a bad solution, except that you don't exactly control other mappings that other devs might have already added so you cannot really tell whether your mapping will not be ignored in favour of another added previously.
Unless we use a LIFO linked list, last in first out, in which case the last added mapping has ultimate priority but beware of not taking precedence over crucial mappings that were not added with the new PROTECT flag, again legacy...

But maybe it should be up to the devs who want to add mappings with their apps to process the list of existing mappings to rebuild a new list that's coherent, keeping old ones and building upon them or fixing them if necessary, then delete existing list and add the new one, rather than making the kernel payload more complex to deal with permutations and indexing and the problems coming from legacy support??

What do you guys think?
 
Last edited:
aldostools said:
The solution is simple, but the user must be aware: delete PS2 Launcher before reinstall it. Or simply install it once.

The other solutions are inconvenient:
- mount the game copying the file instead of link it. It takes around 1 minute to copy a large game.
- unlink the game through the unmount command. It reduces the chance, but not solves the issue if the launcher is reinstalled with the game mounted. I can implement it if it is requested.
Click to expand...
Yeah awareness is the key.

Maybe there could be a check for this, like if the game you are mounting is less than 2MB let the user know there might be an issue with the image. On the other hand maybe its not worth doing anything as this issue is so rare. This is probably not the first time it's happened to someone though.
 
DeViL303 said:
Yep, reinstalling the PS2 Launcher while a game was still mounted, was causing Algols disc images get overwritten due to the symlink. Not sure if there is any solution to an issue like this, maybe just letting people know it can happen is the solution.

Edit: Maybe there is a better way, like what if exiting a PS2 ISO game also caused it to be ejected/unmounted. It would not totally solve this but would probably reduce it a lot. I'm sure some of you guys could come up with something better. Ideally what is required is a one way symlink if there is any way to do that idk?
Click to expand...
Je suis tout à fait d'accord avec ce principe car j'ai eu de nombreux jeux qui se sont fait transformer en "TETRIS" sans me demander mon accord, ceci sur 3 machines (CECH-3004/4004C/4204C) en HFW-4.88.1/HEN-3.1.1. Je n'ai jamais rencontré ce souci avec le HEN-3.0.3 sur ces mêmes consoles ... Un grand MERCI de vous y pencher dessus.

I completely agree with this principle because I had many games that were transformed into "TETRIS" without asking my agreement, this on 3 machines (CECH-3004/4004C/4204C) in HFW- 4.88.1/HEN-3.1.1. I never encountered this problem with the HEN-3.0.3 on these same consoles ... A big THANK YOU for looking into it.
 
bguerville said:
@aldostools @bucanero @Zar @LuanTeles and ps3 devs in general.

I think there is a conceptual issue in map_path that existed before that's still there in my rewrite.

Let's imagine you have a file

/dev_hdd0/folder1/file1.txt

Now say you have 3 mappings


/dev_hdd0/
to
/dev_flash


/dev_hdd0/folder1
to
/dev_flash/folder2


/dev_hdd0/folder1/file1.txt
to
/dev_flash/folder3/file1.txt



The 3 mappings could apply apply to our file1.txt.
Which exactly should the system use?
One could say that the 3rd mapping should probably be applied because it names the file exactly.
But then another could say well it should be the first mapping that wins because it's the one at the lowest level in the tree directory.

Both could be right, it just depends what kind of mapping priority order one wishes to apply.

So we need to choose, we cannot have everything, keeping in mind of course the legacy behaviour to preserve.

And currently, the first one used is the first one found in the mappings linked list therefore it would depend on the order in which they were added.
One could say it's not such a bad solution, except that you don't exactly control other mappings that other devs might have already added so you cannot really tell whether your mapping will not be ignored in favour of another added previously.
Unless we use a LIFO linked list, last in first out, in which case the last added mapping has ultimate priority but beware of not taking precedence over crucial mappings that were not added with the new PROTECT flag, again legacy...

But maybe it should be up to the devs who want to add mappings with their apps to process the list of existing mappings to rebuild a new list that's coherent, keeping old ones and building upon them or fixing them if necessary, then delete existing list and add the new one, rather than making the kernel payload more complex to deal with permutations and indexing and the problems coming from legacy support??

What do you guys think?
Click to expand...

Un grand MERCI à ce que tu fais BEN et aussi à TOUS les autres très bons DEVs qui participent aux meilleurs de ce sites ...
A big THANK YOU to what you do BEN and also to ALL the other very good DEVs who participate in the best of this site...
 
DeViL303 said:
Yeah awareness is the key.

Maybe there could be a check for this, like if the game you are mounting is less than 2MB let the user know there might be an issue with the image. On the other hand maybe its not worth doing anything as this issue is so rare. This is probably not the first time it's happened to someone though.
Click to expand...
Ce souci m'est déjà arrivé plusieurs fois sur au moins l'une de ces machines non compatibles au CFW. C'est très ennuyeux et pratiquement incompréhensible par un néophyte. Il serait très bien que vous vous y penchiez dessus et trouviez une solution viable et définitive à mon humble avis.

This problem has already happened to me several times on at least one of these non-CFW compatible machines. It is very boring and practically incomprehensible by a neophyte. It would be great if you looked into it and found a viable and definitive solution IMHO.
 
bguerville said:
@aldostools @bucanero @Zar @LuanTeles and ps3 devs in general.

I think there is a conceptual issue in map_path that existed before that's still there in my rewrite.

Let's imagine you have a file

/dev_hdd0/folder1/file1.txt

Now say you have 3 mappings


/dev_hdd0/
to
/dev_flash


/dev_hdd0/folder1
to
/dev_flash/folder2


/dev_hdd0/folder1/file1.txt
to
/dev_flash/folder3/file1.txt



The 3 mappings could apply to our file1.txt.
Which exactly should the system use?
One could say that the 3rd mapping should probably be applied because it names the file exactly.
But then another could say well it should be the first mapping that wins because it's the one at the lowest level in the tree directory.

Both could be right, it just depends what kind of mapping priority order one wishes to apply.

So we need to choose, we cannot have everything, keeping in mind of course the legacy behaviour to preserve.

And currently, the first one used is the first one found in the mappings linked list therefore it would depend on the order in which they were added.
One could say it's not such a bad solution, except that you don't exactly control other mappings that other devs might have already added so you cannot really tell whether your mapping will not be ignored in favour of another added previously.
Unless we use a LIFO linked list instead of FIFO, last in first out would make the last added mapping have ultimate priority but beware of not taking precedence over crucial mappings that were not added with the new PROTECT flag to stop deletions, again that's a legacy problem potentially.

But maybe it should be up to the devs who want to add mappings with their apps to process the list of existing mappings to rebuild a new list that's coherent, keeping old ones and building upon them or fixing them if necessary, then delete existing list and add the new one, rather than making the kernel payload more complex to deal with permutations and indexing and the problems coming from legacy support??

What do you guys think?
Click to expand...

No suggestions?
Should I assume none of you cares about this thing, of course I can leave map_path as is if that's what you prefer.

Currently, with the rewrite, the only priority "tuning" that can be applied to a mapping is the priority flag that can be used via syscall 8.
When processing mappings, a first loop is done through the linked list to match to any mapping with the priority flag, if no match is found, another loop is initiated over the entire linked list.

The priority flag can be handy to use in some cases however it doesn't address the issue of priority by file system tree level or by time of addition when various mappings could apply to a path.

The linked list is FIFO, the first added mappings are the first processed for matching without any other consideration.
I should also mention that when a mapping is found in the list, another loop over the linked list is done to check whether the redirected path matches another mapping and should itself also be redirected again.
And again until no new match is found..
All this process is done in FIFO mode.
 
Last edited:
bguerville said:
No suggestions?
Should I assume none of you cares about this thing, of course I can leave map_path as is if that's what you prefer.

Currently, with the rewrite, the only priority "tuning" that can be given to a mapping is the priority flag that can be used via syscall 8.
When processing mappings, a first loop is done through the linked list to match to any mapping with the priority flag, if no match is found, another loop is initiated over the entire linked list.

The priority flag can be handy to use in some cases however it doesn't address the issue of priority by file system tree level or by time of addition when various mappings could apply to a path.
The linked list is FIFO, the first added mappings are the first processed for matching without any other consideration.
Click to expand...

Sorry for not respond earlier, but it was now that I saw your post. I have turned off the notifications (I hate systems dictating me what to do).

In one of the early changes that I made to map paths for MAMBA, I was using LIFO (reverse search). But Cobra Team continued using FIFO, so I decided to switch back to the original method to avoid conflict in homebrews caused by the difference in the search method.

In my opinion, the current systems should stay the way it is or at least the current way should be the default method unless some additional parameter or flag is used explicitly to be searched first.

int sys_map_path(const char *oldpath, const char *newpath, int flags)
{
char *paths[1] = { (char*)oldpath }, *new_paths[1] = { (char*)newpath };
system_call_4(SC_COBRA_SYSCALL8, SYSCALL8_OPCODE_MAP_PATHS, (u64)(u32)paths, (u64)(u32)new_paths, 1, flags);
return (int)p1;
}

sys_map_path("/dev_bdvd", "/dev_usb000/PKG", MAP_PRIORITY); // the new flag would force this map to be found first

If it is changed, the homebrews that were developed with the current way of mapping can be broken.

Here is a realistic use case of map path that requires priority, but it is solved this way:
Code: 
sprintf(path, "/dev_hdd0/GAMES/GT5");
sys_map_path("/app_home", path); // /app_home is first redirected to /dev_hdd0/GAMES/GT5

// /app_home should point to USRDIR, but if it is done the next map path will fail

sprintf(mpath, "%s/PS3_GAME", path);
sys_map_path("/app_home/PS3_GAME", mpath); // /app_home/PS3_GAME is first redirected to /dev_hdd0/GAMES/GT5/PS3_GAME

// Now we can change /app_home

sprintf(mpath, "%s/PS3_GAME/USRDIR", path);
sys_map_path("/app_home", mpath); / /app_home is now redirected to /dev_hdd0/GAMES/GT5/PS3_GAME/USRDIR

If the map order is changed, this code does not work.
BTW this code was simplified, The actual code check if the paths exist.
 
Last edited:
aldostools said:
Sorry for not respond earlier, but it was now that I saw your post. I have turned off the notifications (I hate systems dictating me what to do).

In one of the early changed that I made to map paths for MAMBA, I was using LIFO (reverse search). But Cobra Team continued using FIFO, so I decided to switch back to the original method to avoid conflict in homebrews caused by the difference in the search method.

In my opinion, the current systems should stay the way it is or at least the current way should be the default method unless some additional parameter or flag is used explicitly to be searched first.

int sys_map_path(const char *oldpath, const char *newpath, int flags)
{
char *paths[1] = { (char*)oldpath }, *new_paths[1] = { (char*)newpath };
system_call_4(SC_COBRA_SYSCALL8, SYSCALL8_OPCODE_MAP_PATHS, (u64)(u32)paths, (u64)(u32)new_paths, 1, flags);
return (int)p1;
}

sys_map_path("/dev_bdvd", "/dev_usb000/PKG", MAP_PRIORITY); // the new flag would force this map to be found first

If it is changed, the homebrews that were developed with the current way of mapping can be broken.

Here is a realistic use case of map path that requires priority, but it is solved this way:
Code: 
sprintf(path, "/dev_hdd0/GAMES/GT5");
sys_map_path("/app_home", path); // /app_home is first redirected to /dev_hdd0/GAMES/GT5

// /app_home should point to USRDIR, but if it is done the next map path will fail

sprintf(mpath, "%s/PS3_GAME", path);
sys_map_path("/app_home/PS3_GAME", mpath); // /app_home/PS3_GAME is first redirected to /dev_hdd0/GAMES/GT5/PS3_GAME

// Now we can change /app_home

sprintf(mpath, "%s/PS3_GAME/USRDIR", path);
sys_map_path("/app_home", mpath); / /app_home is now redirected to /dev_hdd0/GAMES/GT5/PS3_GAME/USRDIR

If the map order is changed, this code does not work.
BTW this code was simplified, The actual code check if the paths exist.
Click to expand...
Yeah, that's the heart of the problem really, the current map_parh priority system is totally crap (imho) but changing it would impact legacy code.
 
Sorry I'm late, usually on weekends I go to my beach house and I don't spend much time on the internet.

I would say the 3rd mapping would be the priority over the others as it is an exact path pointing to a file.

Priority list:
1st: File
2nd: Specific Directory
3rd: Generic path/lowest level.

As Aldo said we need to make it compatible wih the legacy homebrews, maybe additional flags are enough
 
LuanTeles said:
Priority list:
1st: File
2nd: Specific Directory
3rd: Generic path/lowest level.
Click to expand...
Exactly the opposite from what it currently is lol

ATM the ONLY priority criterion is the time of addition of the mapping so in the example above, the lower level path mapping would win simply because it was added first.

The priority flag can be used with the new map_path syscall 8 to ensure a mapping gets processed first however if 2+ mappings have the priority flag and match the path partially or fully, then priority is given to the mapping that was added first.
As you can see, unfortunately the priority system cannot be solved with flags alone.
It's a real conundrum, we know the current implementation is flawed, in theory we know how to fix it if we all agreed on new system rules BUT in practice we cannot do anything about it without impacting legacy homebrews.

That's what happens when we start building apps upon flawed or temporary designs, the whole thing ends up coming back to bite you in the ass later on.
 
Last edited:
bguerville said:
Yeah, that's the heart of the problem really, the current map_parh priority system is totally crap (imho) but changing it would impact legacy code.
Click to expand...
Not sure if what im going to say is something you are already considering, but im wondering if the problem could be solved by declaring the same function 2 times, but with different number of arguments

Pretty much... exactly the same code snippet posted by aldo here https://www.psx-place.com/threads/back-to-hen-3-0-3.37918/#post-341208
Same function sys_map_path declared two times with the same name, one without the red "flags" argument (for legacy hombrews), and other with it (for your new implementation)
 
sandungas said:
Not sure if what im going to say is something you are already considering, but im wondering if the problem could be solved by declaring the same function 2 times, but with different number of arguments

Pretty much... exactly the same code snippet posted by aldo here https://www.psx-place.com/threads/back-to-hen-3-0-3.37918/#post-341208
Same function sys_map_path declared two times with the same name, one without the red "flags" argument (for legacy hombrews), and other with it (for your new implementation)
Click to expand...
It's already the case, I had to introduce a new syscall 8 subcode for map_path already, so devs can specify flags as an extra argument and get proper standard error codes return while the old syscalls argument syntax and return type remain "untouched" for legacy reasons.

However that doesn't help for the priority system, we must use FIFO to process the mappings list otherwise legacy homebrews will have issues.

In practice we could keep 2 separate lists operating under different priority order, the old syscalls operating on a FIFO list while the new syscall would operate a list under another priority order, but how could we manage both systems at the same time?
Each time a path is processed by the kernel, the open_path hook searches the mappings list for redirections, it would have to process the FIFO list first, then the other list and finally it would have to reconcile the redirection results somehow, assuming we can find a way to reconcile them in a coherent manner that would guarantee legacy support (I would not hold my breath about that), it would be messy at best..

I don't like it but quite frankly I cannot see a decent way out of this, I am open to suggestions if someone can, that is why I wished to submit this problem to scene contributors before releasing the rewrite.
 
Last edited:
You must log in or register to reply here.

Similar threads

Back
Top