Re: Guidance on individual packages requiring x86_64-v2 baseline ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 12, 2024 at 03:07:02PM +0100, Daniel P. Berrangé 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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.

A little known feature of GCC constructors if you can assign a
priority to them, which controls the ordering (apparently, I did not
test).  Smaller numbers run the constructor earlier / destructor later:

https://maskray.me/blog/2021-11-07-init-ctors-init-array

Numbers <= 100 are reserved, but unless you opt in with the
-Wprio-ctor-dtor flag, you won't get a warning about this.  Maybe we
can add a constructor(0) which checks CPUID?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux