Add support for 2-bay HDD enclosures. The first drive is for WiiU and…

… the second drive is for vWii.

WiiU will recognize only the 1st drive but ignore the 2nd, which works in our favor - WiiU won't even nag you to format the 2nd drive to its proprietary format. usbtoggle is not required. Both drives are adequately powered by an external power brick because all 2-bay enclosures are externally powered. No more Y-cables. (WiiU is very strict about the 500mA USB current limit.)

If you have a RAID enclosure which can be set to RAID 0/1/SPAN/2LUN, set it to 2LUN. On a computer 2LUN simply shows as 2 separate hard drives.

Your homebrew shall remain on an SD card. The WiiU side demands that payload.elf be on an SD card and we can put all vWii homebrews on the same SD card, too. Most homebrews run with IOS 58 which does NOT see the second HDD.

GerbilSoft's code in Nintendont is borrowed to check disk signature. Wii U disks are skipped automatically.

If both disks are readable and contain games, in USB Loader GX, set USB Port to 1 to choose the second hard drive. Until now, the USB Port setting only works with an 'alt' cIOS such as d2x-v10-beta53-alt. The usual advice is to use non-alt cIOS and plug the hard drive to USB port 0. That advice still holds, the only change being that the same USB port 0 is now home to 2 HDDs, with the first hard drive appearing as 'USB Port 0' and the second hard drive appearing as 'USB Port 1'.

Duplicates of binaries are made so that they will show up as different groups in d2x-cios-installer. In my opinion this is the less risky solution in the wrong hands. Leseratte added console= and region= tags to ciosmaps.xml. A new d2x-cios-installer is needed with enhancements to support those new tags and filter the user interface so that only the options pertinent to the user's hardware are shown. However, nothing stops users from using this cIOS with existing the d2x-cios-installer with no such support, and then proceed to install the wrong cIOS on the wrong console (e.g. Wii cIOS on vWii). The safest thing to do IMO is to group them into ciosgroups. Time comes when somebody makes a new d2x-cios-installer it can still support Leseratte's new tags and filter the options. The only cost to this arrangement is file duplication and extra disk/SD card space.

Upped version to 9 to convince WiiXplorer that USB Set Port API is available.

There has been a watchdog thread that reads a random sector every 10 seconds to keep the hard drive awake but it does not have to move the head across the platter that much. Any close-by sector will do.

Change retry to increase timeout exponentially, from 2, 4, to 8 seconds. Minimum is uniformly 2 seconds based on a WD Scorpio Blue 1TB that I pulled from a WD NAS/Router.

The delay from USB reset to get descriptor is increased for broader drive/controller compatibility.

cycle() calls usbstorage_reset() to handle timeouts, but __usbstorage_reset() calls __cycle() to do stuff that has the potential to timeout. Infinite reentrancy. Most of the code is exactly the same as before (d2x-v10), keeping only fixes that are demostrably helpful. Namely, some timeouts are increased, and timeout keeps on increasing as retries are attempted, so that we won't run into a vicious cycle where some operation is ramping up but we keep killing it and restarting it because the timeout we give is too stingy. Secondly, the error handling for an interface failure and a single drive timeout are separate cases. The former continues to use the nuclear strategy of unplugging and hard-resetting the USB interface, but that shall not be applied to the latter. We must not kill the innocent along with the guilty. A soft reset is the appropriate way to deal with a single drive timeout.

Sorry I am deleting my fork and starting over again... Newbie leaked real name in the audit trail... :(

Thanks for continuing to improve the cIOS. I'm not sure if I like the fact that all the changes you've made are now bundled together into one single commit. The approach in the old PR (#8) probably wasn't ideal either as there were a bunch of "revert" commits undoing previous commits, but bundling all the changes into one commit isn't really a good solution for that either. That removes all the comments / descriptions in the previous commit messages, and it removes the "thought process" and information which changes have been made in which order. And it's probably also easier to test if multiple independant changes are made in multiple independant commits.

Also, the git commit ID is not supposed to be seen / interpreted by "normal" users (usually), as that will only be used for temporary releases / artifacts through the CI, and in that case an exact commit makes it easier to track down the exact version (what if there's two commits in the same minute, or commits in different forks, etc.).

I think #8 simply grew too long. I am not sure if my back and forths helps anyone instead of confusing them. In general, I write useful information as comments instead of commit messages. That includes commentary based on what I learned and my understanding of how the code works. Program comments are easier for others when they work on the code in the future than commit messages - I mean, of course both of them are very important, so I filtered and included only the correct/relevant/up-to-date commit messages in the giant commit, which contains the same content, only now more concise. But as a matter of principle I depend only on program comments to convey messages to future developers who are going to work on this code. Even if we are to move away from GitHub to somewhere else, all is not lost.

Ideally, a single commit encapsulates a single feature or fix. But humans like me make mistakes, reverts, multi-tasks on many features at the same time, mix multiple fixes in the same commit... It's hard enough work, and even harder to adhere to the commit guidelines to the letter.

I think almost all real world software is versioned by build number, which in GitHub CI could correspond to the workflow sequence number. I added one more step of minor inconvenience now, you have to look at the list of CI workflows to pinpoint the commit. But to both developers, testers and end-users alike, we now have a clear view of the chronological order of a given binary. That seems like the balance between finding blame quickly and also knowing what is new and what is old quickly. When we involve the community to test they need to be able to report the version of what they tested and for them it is way easier to say 9.0.54 then 9git+7 hexadecimal digits. For us it may be a couple of more clicks to find the commit but I believe the advantages outweight the disadvantages.

First of, I'd like to say I appreciate you making so many useful changes to the cIOS so please don't misunderstand me, I'm not saying I don't like your work.

As for the version numbers, yeah, all "real-world software" is versioned by a version number, but that doesn't have to be a running sequence number. While your approach has advantages, it also has disadvanges.

It breaks reproducible builds (since you'll need to hack the scripts in order to reproduce a byte-by-byte identical binary for a previous commit, since you'd need to trigger a new build with a new workflow ID. By using a git hash, that'll happen automatically, and that is something I explicitly wanted to support (I believe there's even a commit somewhere in here that will compile to a byte-identical copy of the old d2x v10 cIOS).
It breaks if people fork the repository, as the first build in my repo and the first build in your repo would both have the version number 9.0.1. By using a git hash, each distinct version gets its own distinct version number (unless you get collisions in the short commit hash)
It breaks compiling outside of Github - I can no longer compile the cIOS on my local development machine without manually setting the workflow ID to some useful value. I would need to know the exact workflow ID for a given version in order to build a byte-identical binary, which brings me to the next point:
There is no "git commit" to "version number / workflow ID" mapping anywhere, so without Github there would be no way to figure out which git commit hash belongs to a given version number or vice versa. Also, I'm not sure if Github keeps the workflow ID history forever. In a year, if someone tells me he's using the test version with workflow ID 1234, how do I figure out which git commit that belongs to once the log files on Github are gone?
It leads to huge, unreadable version numbers. I prefer "Version 9.0", "Version 9.1", "Version 9.2" over "version 9.0.22", "version 9.0.814" and "version 9.0.1734". While that might just be personal preference, it's also less confusing to the users. In general, I believe that version numbers with git hashes (like v9-git+abcdef12) are intended to be used during development when there's lots of changes in quick succession, and once a given version has matured enough to be released to the public it should get a "normal-looking" version number. It's very rare that you see normal programs having their sequential build ID embedded in the (major) version number, it's usually just provided in addition to a normal version number).

Yes, software is supposed to have a meaningful version number, but in my opinion that only applies to software that's actually released to end users in form of a github release (which pins a readable version number to a given git commit). There is no advantage over a nightly build being labelled "9.0.1734" instead of "9.0-89abcdef". Your approach would make it easier for users to identify whether a given version is older or newer than another, but in practice, that's going to happen using the major and minor version number. The end user doesn't really need to know if "9.0-abc" or "9.0-def" is newer, does he?

If I'm misunderstanding your changes and one (or multiple) of my points above do not apply to your changes, please correct me.

As for commit messages / comments - yes, comments in the source code itself are helpful and necessary (thanks for putting comments on all of your changes), but seperated commits are also helpful - if this PR gets merged with all the changes in one commit, and later on someone figures out there's a bug, then there is no easy way to figure out which of your many changes caused the bug, as you have 2-drive-compatibility, timing changes, the read watchdog and the reset code changes all in one commit. A bisect will just lead to this huge commit as the culprit. If these were seperated into four different commits, one could test and verify them independantly if issues occur.

Thanks for your explanation. Now I understand it's binary reproducibility that you are after. In that case it can only depend on git HEAD. There are only 2 ways to achieve this. The first is to use a decimal timestamp with 12 digits (6 date + 6 time to the seconds). The second is to use the 7 hex digit commit hash. I think the former is more informative, but too long when displayed on the screen. I will go back to the latter.

Sorry for misunderstanding your vision. I thought it was about proving parity with v10 at some point in time, and then since going forward it is of course going to divert from v10, there will be no longer binary reproducibility with v10. I didn't know it was about d2xl itself, and some attribute that we want to keep in perpetuality.

Leseratte10 / d2xl-cios

Add support for 2-bay HDD enclosures. The first drive is for WiiU and… #11