New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add fat32/exfat fragmentation tolerance #673
Conversation
was doing same stuff since it's very very boring. btw, mostlyclean is the name for this kind of target to clean what should be rebuild. |
@@ -314,6 +312,10 @@ clean: | |||
echo "-pc tools" | |||
$(MAKE) -C pc clean | |||
|
|||
realclean: clean |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
realclean -> clean
clean -> mostlyclean
https://www.gnu.org/software/make/manual/html_node/Goals.html
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I disagree. We're talking about deleting external source files. We not talking about deleting compiled files.
From the link you provided:
mostlyclean
Like ‘clean’, but may refrain from deleting a few files that people normally don’t want to recompile. For example, the ‘mostlyclean’ target for GCC does not delete libgcc.a, because recompiling it is rarely necessary and takes a lot of time.
distclean
realclean
clobber
Any of these targets might be defined to delete more files than ‘clean’ does. For example, this would delete configuration files or links that you would normally create as preparation for compilation, even if the makefile itself cannot create these files.
Which is exactly what I think we want:
- clean: delete all compiled files
- realclean: delete more, like the entire git repository
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a point of view. I thought we can avoid rebuild the compiled lang so i think mostlyclean ...
src/bdmsupport.c
Outdated
|
||
// Get fragment list | ||
fileXioIoctl2(fd, USBMASS_IOCTL_GET_FRAGLIST, NULL, 0, (void *)&part_frags, sizeof(bd_fraglist_t)); | ||
if ((settings->frags.count + part_frags.count) > 10) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe 10 can be delivered from header? just in case we increase the limit so do not forget to increase it here too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. But unfortunately I didn't add it to the header in ps2sdk :(. There's also another thing bothering me. Instead of 10 fragments it would be better to be able to ask for more (or dynamic) number of fragments.
Having more fragments could also make this new structure compatible with HDD fragments:
Open-PS2-Loader/modules/iopcore/cdvdman/atad.h
Lines 77 to 84 in 08fc57b
typedef struct | |
{ | |
u32 part_offset; // in MB | |
u32 data_start; // in sectors | |
u32 part_size; // in KB | |
} hdl_partspecs_t; | |
#define HDL_NUM_PART_SPECS 65 |
Perhaps the best solution is to make the function (USBMASS_IOCTL_GET_FRAGLIST
) dynamic, and pass a fixed amount of 65 fragments to the iopcore? Then as a second step, make the HDD and BDM fragments use the same structure and code?
I've make the fragmentation tolerance much more flexible now, and increased the maximum number of fragments 64. Currently this PR will fail untill the PR in ps2sdk has been merged. |
Will this work with ZSO? Why does the code fill only fragmented files in ISO? Will you leave it to @JoseAaronLopezGarcia add? |
Yes, this should work with ZSO also. It's the fragments of the 'game file', no matter the file extension. |
It makes sense I was just looking at the code and not the fact that the zso is just iso compressed |
Also note that the fragmentation support costs 512b of extra IOP RAM. |
This is definitely a great thing for new iop functions and for games that require more ram |
Add fat32/exfat fragmentation tolerance
Pull Request checklist
Note: these are not necessarily requirements
Pull Request description
This PR adds fragmentation support to the ingame / iopcore. This applies to all BDM devices using fat32/exFat. Up to 10 fragments will be possible. If there's more fragments then the same old fragmentation message should appear.
Also in this PR I made the cloning of the lang folder a little less aggressive. 'make clean all' will no longer remove the lang folder, and only update the lang folder. 'make realclean all' will also delete the lang folder, and re-clone it.