On Mon, 14 Mar 2022 19:01:06 +0000 Daniel P. Berrangé <berra...@redhat.com> wrote:
> We have a general purpose platform support policy > > https://www.qemu.org/docs/master/about/build-platforms.html > > where the common rule ends up being "the current major release, > and the previous major release for 2 years overlap". > > The question is what counts as a major release from a Solaris > POV ? In terms of long life distros, our policy gives about > 4-5 years of supportable life in the best case. I wouldn't > want to go beyond that ballpark for Solaris. Can we come up > with an interpration of our policy to map to Solaris that > doesn't tie our hands for longer than 4-5 years worst case. FWIW, some relevant Solaris version numbers, as I understand it: 11.4.42 CBE: public release March 2022. (Non-production use only, rolling release schedule.) 11.4: public release August 2018. 11.3: public release October 2015. Going by the minor version number (11.3 vs 11.4) sounds similar to Linux distros; they've come out every few years in the past. But I don't know how this is going to look with the CBE stuff in the future, or if anyone knows (it's very new). > IOW, we certainly do NOT need to support arbitrarily old > Solaris. If madvise has done what we need for 4-5 years, > then we can likely not need to test for it, and just assume > its existance. This just requires someone to specify how > we interpret our build platform policy to exclude older > Solaris. Specifically for the madvise() prototype workaround, I looked a little bit into what version changes actually matter. I think all of Solaris 11 is probably okay without the workaround (I can check back to Solaris 11.1, but just by looking at the mman.h header, not actually testing a build), because we specify -D__EXTENSIONS__. Illumos and Solaris 10 look like they would need the workaround. So practically speaking for this patchset, it seems more like a question of Illumos support. -- Andrew Deason adea...@sinenomine.net
