From owner-svn-src-all@FreeBSD.ORG Tue Apr 19 18:50:26 2011 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 072851065675; Tue, 19 Apr 2011 18:50:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C93418FC0A; Tue, 19 Apr 2011 18:50:25 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 530F046B3C; Tue, 19 Apr 2011 14:50:25 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D244A8A02A; Tue, 19 Apr 2011 14:50:24 -0400 (EDT) From: John Baldwin To: Warner Losh Date: Tue, 19 Apr 2011 14:26:04 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <201104172103.p3HL3Ntb049564@svn.freebsd.org> <201104190840.29535.jhb@freebsd.org> <6ED7B30B-B545-4E38-A157-5008A1615DBC@bsdimp.com> In-Reply-To: <6ED7B30B-B545-4E38-A157-5008A1615DBC@bsdimp.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201104191426.04591.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 19 Apr 2011 14:50:24 -0400 (EDT) Cc: Doug Barton , Pawel Jakub Dawidek , Roman Divacky , Dimitry Andric , src-committers@freebsd.org, svn-src-head@freebsd.org, svn-src-all@freebsd.org Subject: Re: svn commit: r220755 - in head: . contrib/gcc/doc contrib/gcc/objc contrib/libobjc etc/mtree gnu/lib gnu/lib/libobjc gnu/usr.bin/cc gnu/usr.bin/cc/cc1obj gnu/usr.bin/cc/cc_tools gnu/usr.bin/cc/doc s... X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 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: Tue, 19 Apr 2011 18:50:26 -0000 On Tuesday, April 19, 2011 2:04:53 pm Warner Losh wrote: > > On Apr 19, 2011, at 6:40 AM, John Baldwin wrote: > > > On Monday, April 18, 2011 3:59:45 pm Warner Losh wrote: > >> > >> On Apr 18, 2011, at 12:18 PM, Doug Barton wrote: > >> > >>> On 04/18/2011 11:14, Pawel Jakub Dawidek wrote: > >>>> On Mon, Apr 18, 2011 at 11:06:42AM -0600, Warner Losh wrote: > >>>>> > >>>>> On Apr 18, 2011, at 1:01 AM, Roman Divacky wrote: > >>>>> > >>>>>> please mark this in src/UPDATING, maybe bump freebsd_version too? > >>>>> > >>>>> Please do not bump freebsd_version just for this. Ports wishing to know > > can go off the last bump, if there are any. > >>>>> > >>>>> Every freebsd_version bump forces rebuilding all modules and such and is > > a pita. > >>>> > >>>> I agree that this is a PITA, but there also should be a way to force > >>>> module load even on version bump. This is PITA especially for > >>>> developers. > >>> > >>> .... who make up a tiny percentage of the FreeBSD user community. > > Seriously? We're going to whine because version bumps cause a little extra > > compile time? > >> > >> The problem usually manifests itself when I got to debug a new problem, load > > a driver and find I have to rebuild everything else to use it, which forces an > > extra reboot on the machine in question. Sometimes this can be quite > > disruptive to other things that machine is doing. > > > > But that is only true if your source tree doesn't match your installed world. > > If the new driver is standalone and you build it as a module, it will use the > > headers from /sys and will work fine. > > It is rarely the case that my source matches my install world. My kernel and userland are asynchronously updated when I'm doing heavy kernel development. My sources are updated all the time to pull in useful things that I need. When I'm in this mode, I carefully track what's changed to make sure there were no recompile the world events. When a userland thing changes that bumps freebsd_version, I have to recompile the kernel and reboot, even though there's no need to do so. This is especially annoying when it happens a few times within one week, since it is a hit to my productivity each time it happens. There's no great need to have userland features identified with the fidelity of a few dozen commits in - current. A few hundred or more would suffice for ports and those interested, so bumping more than once a week provides almost no benefit, but inflicts some pain. Hmm, my development tree never matches my /usr/src either, but I never run into this. I always build a kernel in a p4 or whatever checkout and do 'make install KERNEL=foo' (or make installkernel INSTKERNNAME=foo) along with 'nextboot -k foo' (or 'boot foo' at the loader prompt). My current testboxes actually tend to have 7.x worlds and I just boot 9 kernels on them all the time. But by building a new kernel each time I never hit problems with __FreeBSD_version checks. However, all that said, I would have no problem having something you can set in make.conf or on the command line to disable the check for a given module build. Oh, one other thing, if you stick your module directory in a kernel tree that matches whatever the running kernel is, then that also works fine. I do this a lot where I've booted a 9.0 kernel on a 7.x machine, and then have a sys/modules/foo in that source tree and I can build the module from that directory and load/unload it without any problems. > >> In this case, there was a new kernel thing just after, so it turned out OK. > > But let's not gratuitously bump the version since the granularity we have > > already allows the ports to make good choices on when to leave something in or > > out. > > > > Except that that directly contradicts our previously established policy that > > these version bumps are cheap and that we should do more of them (this came up > > a few years ago when we changed the policy so that the new "stable" branch > > after a release starts at N + 500 (e.g. 802500) rather than N + 100 to give > > more room for version bumps on current). > > We have never said that version bumps were totally cheap. In -current, there's little benefit to bumping things more often than once a week. Since we generally develop stable for more than 2 years, 100 wasn't enough at the one a week rate. But that doesn't mean that 5 per week is OK either, since now we suddenly have room for them. I'm strongly suggesting that for userland-only changes that one check to see when the last bump was and if it is less than a few days (or a week), then to piggyback off the last one/next one to discriminate whether to use an old feature, or start using a new feature. Especially for retroactive bumps that happen disconnected to the original feature going in. I can't find the original thread, but we did in fact say that. :) However, I'd be happy to only have one a week or what not. Big interface changes should generally have them though, especially if they affect KPIs used by out of tree drivers or other software in ports. -- John Baldwin