On Wed, Jun 12, 2024 at 10:07 AM Daniel P. Berrangé berrange@redhat.com wrote:
On Wed, Jun 12, 2024 at 09:59:25AM -0400, Stephen Gallagher wrote:
On Wed, Jun 12, 2024 at 9:55 AM Daniel P. Berrangé berrange@redhat.com wrote:
On Wed, Jun 12, 2024 at 09:51:34AM -0400, Stephen Gallagher wrote:
On Wed, Jun 12, 2024 at 8:41 AM Daniel P. Berrangé berrange@redhat.com wrote:
IOW, if [when] we rebase Fedora to the next QEMU upstream release, users with older x86_64 hardware would likely be unable to run QEMU, from F41 onwards, unless some TBD action is taken.
Thus I'm wondering whether Fedora has any policy or guidance on handling such a situation both in general, and more specifically for "critical path" packages, if that difference is relevant ? The packaging guidelines aren't especially explicit about this situation, unless I've missed something beyond the "compiler flags" and "architecture support" sections.
Absent a project-wide decision to move to the newer baseline, I think the best approach we can take would be to find some way to communicate to the user that the software isn't usable. In the case of Qemu, does the application report an error or crash if it's run on hardware without the requisite baseline?
I've not tested, but I would expect it to crash attempting to execute an illegal instruction
OK, that's a situation that will lead to annoying and unresolvable bug reports. Would it be possible to put something in place that would check processor capabilities early in execution before hitting any of the affected instructions?
Not trivial as a bunch of code executes from ELF constructors before main() starts.
Wrapper application that just does feature tests and then fork/exec()'s the real application?