Single binary compilation

[uyjulian]

It would be interesting to have a single binary for all IOP related functionality. This would possibly allow the following:

• Not restricted to libc functions inside sysclib, so for example you could use strnlen
• Change the ABI to e.g. n32
• Link time optimization
• .iopmod section support code can be removed from Linux
• Remove the need for tools to manipulate the .iopmod section
• Module loading code can be left out, freeing up more IOP memory for e.g. cache

Since there is less need for runtime loading/unloading of modules in the Linux kernel environment compared to the EE realtime kernel environment, I think it would be a good idea.

This would require reimplementation of the ROM modules (which I am currently working on for ps2sdk).

[frno7]

Interesting ideas! Especially the complete ROM replacement. But no modularity, at all? Users with no expansion bay hardware attached may not want to allocate memory on unused IOP drivers. Some users may want a network driver, but no harddisk driver, or vice versa, even if hardware for both exist.

One useful memory optimisation that Linux does is to free init code once initialisation is done. After all, that code will never run again, and so its memory could be reused. Memory could be saved on the IOP likewise.

Related note regarding IOP driver design: For Linux and ease of use, it’s important that a single kernel works on all compatible PS2 hardware variants, and autoconfigures itself accordingly, as opposed to compiling kernels that work on specific PS2 hardware but crashes or refuses to start on others, due to hardware differences; the 2.x and 3.x PS2 Linux versions are very problematic and frustrating in this respect. The proper way to do this, I think, is that drivers can disable themselves, with an appropriate error message, without crashing, if hardware they require is missing.

[rickgaiser]

Modularity is IMO one of the great features the IOP has. If we have a single binary, then it will serve the 1 specific goal it is compiled for. What happens next is a lot of compile time options, and a lot of 'single' binaries for each specific goal. Each added option (yes/no hdd? yes/no eth?) will DOUBLE the number of 'single' binaries.

[frno7]

I agree that modularity is important, @rickgaiser. I think @uyjulian suggests interesting ideas, for example how to make better use of the limited IOP memory. Would it be possible to make more dynamic use of memory? For example, an ATA driver could use all free memory for its buffers, as opposed to the fixed size buffers most drivers currently use. And then, when some other IOP service needs some amount of memory, the ATA driver could shrink its buffers automatically.

Another way to save a bit of IOP memory is to move its linker, and perhaps other services, to the EE. IOP memory fragmentation could be reduced if code is dynamically relocatable, as necessary.

Regarding link time optimisation: it would be interesting to see how much this gives. Some important cases can perhaps be reworked to avoid performance problems related to linking.

Regarding the n32 ABI: indeed, the IRX format is a hassle, but at least we do have some tooling for it. Perhaps the IOP linker could be amended to accept standard n32 ELFs? Perhaps this could be handled by the EE, so that the IOP linker could be uninstalled and thereby save some IOP memory?

Regarding IOP modules: the Linux kernel has a fairly complete implementation of IRX dependency resolution and automatic prelinking in drivers/ps2/iop-module.c, including IRX version checks and so on. Can PS2SDK do automatic IRX prelinking as well?

It would be interesting to expose much more of the IOP internals through the Linux kernel sysfs. Some is available already, for example drivers/ps2/iop-module-sysfs.c that gives some details about the loaded IOP modules. More could be done, for example structured details about how IOP memory is alloced/fragmented, threads running, threads waiting, IRQ services installed, and so on. I don’t know if the IOP does any kind of thread accounting, for example thread running times. That would be interesting too.

[frno7]

also this issue can be closed now

@AKuHAK, I believe this issue #6 is a different concept compared with #8, but maybe @uyjulian can elaborate?

[uyjulian]

Yes, it means statically link all modules as one ELF binary, instead of multiple ELF files or multiple ELF files in a IOPRP image.