From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9271CC433F5 for ; Mon, 14 Mar 2022 21:34:40 +0000 (UTC) Received: from localhost ([::1]:42334 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nTsKt-0000me-Bp for qemu-devel@archiver.kernel.org; Mon, 14 Mar 2022 17:34:39 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48534) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nTsJZ-0008JF-CW for qemu-devel@nongnu.org; Mon, 14 Mar 2022 17:33:17 -0400 Received: from smtp123.iad3a.emailsrvr.com ([173.203.187.123]:38436) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nTsJX-0006AU-Cu for qemu-devel@nongnu.org; Mon, 14 Mar 2022 17:33:17 -0400 X-Auth-ID: adeason@sinenomine.net Received: by smtp24.relay.iad3a.emailsrvr.com (Authenticated sender: adeason-AT-sinenomine.net) with ESMTPSA id BF90324A62; Mon, 14 Mar 2022 17:33:13 -0400 (EDT) Date: Mon, 14 Mar 2022 16:33:13 -0500 From: Andrew Deason To: Daniel P. =?UTF-8?B?QmVycmFuZ8Op?= Subject: Re: [PATCH 1/2] util/osdep: Avoid madvise proto on modern Solaris Message-Id: <20220314163313.5795fa36206526826fe72d10@sinenomine.net> In-Reply-To: References: <20220314154557.306-1-adeason@sinenomine.net> <20220314154557.306-2-adeason@sinenomine.net> <20220314131800.89dbb505371e68c7ad382795@sinenomine.net> Organization: Sine Nomine Associates X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Classification-ID: 1d8a0fa7-eb55-4b14-b006-db08e31c35ec-1-1 Received-SPF: pass client-ip=173.203.187.123; envelope-from=adeason@sinenomine.net; helo=smtp123.iad3a.emailsrvr.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Eduardo Habkost , Peter Maydell , "Michael S. Tsirkin" , Richard Henderson , qemu-devel@nongnu.org, Paolo Bonzini , Ani Sinha , Igor Mammedov Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Mon, 14 Mar 2022 19:01:06 +0000 Daniel P. Berrangé 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 adeason@sinenomine.net