Remove max_device_infos limit in riscv mux target

[dlopr]

There was a harcoded maximum of devices used as static size for a std::array.

This removes the limit and uses a dynamically sized std::vector instead.

[hvdijk]

Thanks for the PR! The main idea looks good. Are you intending for it to still be possible to have invalid device info (in which case it will still need to be handled), or are you wanting to make that impossible?

[hvdijk]

If we end up with invalid device info, shouldn't we still bail out? Alternatively, if we can ensure that info is always valid so that we no longer have to check, that would also be okay but in that case we should probably remove is_valid() entirely.

[dlopr]

That's something that could happen with the std:array approach: only actual devices are initialized and the excess of entries in the array capacity are not.

With a vector, the size of the vector tells you the number of devices.

[hvdijk]

This assumes that an uninitialized device info is the only way to end up with an invalid device info though. That is an assumption we currently try to avoid making: the code does:

    auto &dev_info = device_infos.emplace_back();
    dev_info.update_from_hal_info(hal_dev_info);
    dev_info.hal_device_index = i;
    // device info should be valid at this point
    assert(dev_info.is_valid());

Consider what the assert does here: it accounts for the possibility that there are bugs in update_from_hal_info that leaves dev_info in an invalid state, and ensures that in debug builds we get a crash due to an assertion failure. In release builds, the assert does nothing, we would carry on with the invalid device info already added to device_infos. And then, the removal of the if (!info.is_valid()) break; condition would cause that invalid device info to be used.

We could change the way we update dev_info to ensure that invalid device infos are never added to the vector (or possibly even that they can never exist in the first place), but unless we include such a change in this PR, I think we need to allow for the possibility that the vector contains invalid device infos and keep this if (!info.is_valid()) break; in.

[dlopr]

I don't really mind, but in my opinion it doesn't make sense to have both an assert and a check. You said it yourself, the assert means the device_info should be valid at that point. If that's not correct and it's expected that the initialization may fail, that's not a good use of an assert.

Also note, that the initialization indeed cannot fail. It's just a bunch of assignments of variables of builtin types that ends with valid = true.

[hvdijk]

I don't really mind

Thanks, please do go ahead and restore the runtime check.

in my opinion it doesn't make sense to have both an assert and a check. You said it yourself, the assert means the device_info should be valid at that point. If that's not correct and it's expected that the initialization may fail, that's not a good use of an assert.

The way I look at it is not the only way of looking at it, I'll grant you that, but it is: if the initialization fails, that is a bug and it is useful for the assert to flag that early when possible. But if it's a bug that we can expect to encounter, not just in the current code but also after future changes, it's also a bug for other code to not handle that.

Also note, that the initialization indeed cannot fail. It's just a bunch of assignments of variables of builtin types that ends with valid = true.

True, but that's only what the code looks like now. It seems reasonable to me to expect future changes there, and for future changes to not take an in-depth look at how the result is used.

Your removal of the runtime check is not necessarily bad, maybe we do end up wanting that, but at the very least, given that it is not required for this PR, and not obviously beneficial, if we do end up with it, I would prefer to have that as a separate change, at least, so that if it does end up causing an issue, we would be able to revert just that and not the rest of this PR.