From owner-svn-src-all@FreeBSD.ORG Tue Apr 19 12:40:31 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 35C9A106564A; Tue, 19 Apr 2011 12:40:31 +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 060878FC08; Tue, 19 Apr 2011 12:40:31 +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 9425946B42; Tue, 19 Apr 2011 08:40:30 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 322BE8A01B; Tue, 19 Apr 2011 08:40:30 -0400 (EDT) From: John Baldwin To: Warner Losh Date: Tue, 19 Apr 2011 08:40:29 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <201104172103.p3HL3Ntb049564@svn.freebsd.org> <4DAC8060.2070002@FreeBSD.org> <92422863-8655-4FDE-A1E9-5EE1F46DA5BC@bsdimp.com> In-Reply-To: <92422863-8655-4FDE-A1E9-5EE1F46DA5BC@bsdimp.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201104190840.29535.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 19 Apr 2011 08:40:30 -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 12:40:31 -0000 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. If the new driver is part of the source tree, you do not have to upgrade the entire world, just build a kernel + moduleset, install that to /boot/foo and reboot into the foo kernel. Yes, that can require a reboot, but lots of kernel development requires reboots. > 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). -- John Baldwin