OK, that sounds more possible. I'm still not sure I really get the point.
Is it just so people don't have to figure out which diskboot.bin to put on their camera ? It may sound harsh, but I'm not sure that the people who can't figure how to use vers.req and download the right file are going to benefit much from CHDK. Things are currently confusing to new users because the documentation is a mess, but the actual process is reasonably simple.
That said, figuring out which camera you are on shouldn't be too hard (there's strings you could look for, or you could CRC/hash some of the ROM), but at that point you won't have enough of an OS to actually load it. I guess you could store the minimal set of offsets required for every known camera.
a) rename/copy/vector the appropriate CHDK build for the firmware from a complete list on the card and reboot into it (PhyrePhoX suggestion), or
Possible. IMO, it would be much more desirable to have this act as an installer rather than run every time the camera boots. In other words, you copy something to your SD card, the first time it loads, it figures out what camera you have, and replaces itself with the correct diskboot.bin. If you were clever, you could have it do this every time the camera changes.
Still, the whole idea of putting every build of CHDK on the card just strikes me a giant kludge.
b) have a table of entry points for all the known camera firmware versions, and have a single CHDK build that dynamically configures itself to use the appropriate entry points from the table for the camera the card is placed in. The CHDK code would also need to use normal control statements wherever code is currently statically #ifdef'd (conditionally compiled)
There's a lot more to CHDK than just entry points. Large parts of the canon firmware are disassembled and modified. You'd have to do the same process at runtime, or have loadable objects for those files. Moving all the #ifdefs and and #defines to variables would negatively impact the memory footprint at the very least.
If you want to take this idea further, you'll definitely have to dig into the CHDK code. As I've expressed above, it strikes me as a waste of effort, and likely to negatively impact both function and maintainability.
There is one direction that strikes me as possibly desirable: If you implement some sort of loadable module system (like linux kernel modules) you
might be able to reasonably break things down into platform specific and not, and then load whichever bits you need for the current camera. This would be major surgery, but there would be many other benefits to such a system, so it wouldn't be wasted effort in any case.
Handling different firmware revisions of the same camera might not be too bad. You'd have to fix up all the address and the asm boot code, but that should be fairly straightforward using something kind of like a relocation table.
