From owner-svn-src-all@freebsd.org Fri Oct 23 22:06:30 2015 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 10F2CA1CB51; Fri, 23 Oct 2015 22:06:30 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-yk0-f174.google.com (mail-yk0-f174.google.com [209.85.160.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BA886ABF; Fri, 23 Oct 2015 22:06:29 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by ykdr3 with SMTP id r3so134425541ykd.1; Fri, 23 Oct 2015 15:06:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=hj0k/njBf4QjtAKTQQ9FR5ovErt4Atcj9XkbF47lruk=; b=RXiJeIepYE+rrKuOX77TDLSEN3R2nD+9dxTHxZSHnmX8Me662IE8JQqQ5BT2Rbgg1p PC/s9UFBD18fDFElxk5lqXKjQ2q2Z4w4xYaVvJNHzECRr8y+LjZx1Imptyv7XI5PK0OH Hm2Y8QvG8GugbXDK6CBY0576a4zdV8cQyby8kHdEsejicUdpogD8ijHfbqB/qUg6h5Cl UC/RsBqJ8lcuNxFLhTQbNvKMHGZ9Gv+ToYrSRttZYU9pFha2EREwbC9LmGpd3xqw5iFj oNldz9mPhSj2EfpCrFyIG2C0MxkHOeXB3ZLC/Bze93GeU4/RkakOC3XvZt+p2O7fLJbP uF5Q== X-Received: by 10.129.75.208 with SMTP id y199mr19123587ywa.48.1445637982609; Fri, 23 Oct 2015 15:06:22 -0700 (PDT) Received: from mail-yk0-f178.google.com (mail-yk0-f178.google.com. [209.85.160.178]) by smtp.gmail.com with ESMTPSA id l188sm15494711ywd.3.2015.10.23.15.06.22 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Oct 2015 15:06:22 -0700 (PDT) Received: by yknn9 with SMTP id n9so134228676ykn.0; Fri, 23 Oct 2015 15:06:22 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.13.237.199 with SMTP id w190mr16778865ywe.338.1445637982170; Fri, 23 Oct 2015 15:06:22 -0700 (PDT) Reply-To: cem@FreeBSD.org Received: by 10.37.203.75 with HTTP; Fri, 23 Oct 2015 15:06:22 -0700 (PDT) In-Reply-To: <1445637372.91534.38.camel@freebsd.org> References: <201510222303.t9MN37D2093845@repo.freebsd.org> <20151023210604.GA12348@lonesome.com> <1445637372.91534.38.camel@freebsd.org> Date: Fri, 23 Oct 2015 15:06:22 -0700 Message-ID: Subject: Re: svn commit: r289773 - in head: sbin/sysctl sys/kern sys/sys From: Conrad Meyer To: Ian Lepore Cc: "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , "src-committers@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 22:06:30 -0000 On Fri, Oct 23, 2015 at 2:56 PM, Ian Lepore wrote: > On Fri, 2015-10-23 at 14:43 -0700, Conrad Meyer wrote: >> On Fri, Oct 23, 2015 at 2:06 PM, Mark Linimon >> wrote: >> > On Fri, Oct 23, 2015 at 08:09:35AM -0700, Conrad Meyer wrote: >> > > What is __FreeBSD_version and why would it be bumped? >> > >> > >> > >> > This variable exists to tell the Ports Collection, among others, >> > that "something has changed that may require you to patch and/or >> > recompile." > > Another is making it possible to test for new features that > arrived with a given version, and that's what you've done. > > Suppose I maintain an out-of-tree driver that has to build on several > versions, and uint16 is really the right type for its sysctl but it > also has to work on versions that don't have that support. That tends > to get handled with things like #if __FreeBSD_version < NNNNNNNN. > (Contrived example here maybe, since if uint32 worked on one version, > I'd likely use it on all of versions.) Suppose you did. The change lends itself to "#ifdef CTLTYPE_U16" =E2=80=94 = in this truly contrived scenario. Any other check is redundant or less specific. (As Ngie points out, checking an absolute version doesn't do you a lot of good in the face of backports/cherry-picks.) > One of the implications of the feature-availability testing is that > when you MFC your change, you also have to bump the version number on > that branch (independently, not via MFC). Not a problem =E2=80=94 the MFC After field was intentionally omitted (i.e.= , "MFC After: never"). This is only intended for CURRENT. Best, Conrad