From owner-svn-src-head@FreeBSD.ORG Tue Jul 30 21:41:02 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 95BE982A; Tue, 30 Jul 2013 21:41:02 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 24F1E2C75; Tue, 30 Jul 2013 21:41:01 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.7/8.14.7/ALCHEMY.FRANKEN.DE) with ESMTP id r6ULf02Z061591; Tue, 30 Jul 2013 23:41:00 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.7/8.14.7/Submit) id r6ULf0CT061590; Tue, 30 Jul 2013 23:41:00 +0200 (CEST) (envelope-from marius) Date: Tue, 30 Jul 2013 23:41:00 +0200 From: Marius Strobl To: Edward Tomasz Napiera?a Subject: Re: svn commit: r249410 - in head/sys: amd64/conf arm/conf cam/ctl conf i386/conf ia64/conf modules/ctl sparc64/conf Message-ID: <20130730214100.GO56034@alchemy.franken.de> References: <201304121625.r3CGP3Dv068400@svn.freebsd.org> <20130729203848.GG948@alchemy.franken.de> <517A021B-6C7B-48C3-9AC2-CBA937BBAC80@FreeBSD.org> <20130730202820.GM56034@alchemy.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, ken@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 21:41:02 -0000 On Tue, Jul 30, 2013 at 10:40:49PM +0200, Edward Tomasz Napiera?a wrote: > Wiadomo?? napisana przez Marius Strobl w dniu 30 lip 2013, o godz. 22:28: > > On Tue, Jul 30, 2013 at 09:57:21PM +0200, Edward Tomasz Napiera?a wrote: > >> Wiadomo?? napisana przez Marius Strobl w dniu 29 lip 2013, o godz. 22:38: > >>> On Fri, Apr 12, 2013 at 04:25:03PM +0000, Edward Tomasz Napierala wrote: > >>>> Author: trasz > >>>> Date: Fri Apr 12 16:25:03 2013 > >>>> New Revision: 249410 > >>>> URL: http://svnweb.freebsd.org/changeset/base/249410 > >>>> > >>>> Log: > >>>> Remove ctl(4) from GENERIC. Also remove 'options CTL_DISABLE' > >>>> and kern.cam.ctl.disable tunable; those were introduced as a workaround > >>>> to make it possible to boot GENERIC on low memory machines. > >>>> > >>>> With ctl(4) being built as a module and automatically loaded by ctladm(8), > >>>> this makes CTL work out of the box. > >>>> > >>> > >>> Uhm, shouldn't r249328 and the above change be MFCed to stable/9 in > >>> order to reduce the default memory footprint there? > >> > >> Yup, my bad. I'm waiting for reply from re@ whether it's a good thing > >> to do at this point of the release process. > >> > > > > Yeah, I saw that request and was looking into what it would actually > > take to remove ctl(4) from GENERICs in stable/9. Unfortunately, it's > > not exactly as straight forward as MFCing the two above revisions 1:1. > > For one, IMO kern.cam.ctl.disable shouldn't be removed there in case > > someone uses an old kernel configuration file having "device ctl" but > > relies on that tunable to work. That's no big deal, though, and makes > > the merge even less intrusive. However, the real problem is that ctl.ko > > currently is globally disabled in stable/9 as it doesn't build with PAE/ > > XEN. Actually, the compiler is right to complain as a 32-bit void-pointer > > is casted to a 64-bit integer in that case. What I don't get so far is > > why on earth this doesn't break compilation in head ... > > Damn. Now that you mention it... yeah, it was me who disconnected it, > in r249530. I had no idea what's going on either. > Well, could be a clang vs. GCC thing but I currently can't build an i386 world from head with GCC due to yet another breakage in order to verify that *sigh*. Anyway, it seems support for bus address still is to be properly implemented in ctl(4) so it doesn't make much sense to fiddle with making that part compile on all architectures. The bottom line probably is that the least intrusive thing to do is to request an approval for a direct commit to stable/9 reverting r249530 but disabling ctl.ko for XEN with something like the below patch. I did run that through a universe build and it didn't break anything. Marius Index: i386/conf/XEN =================================================================== --- i386/conf/XEN (revision 253803) +++ i386/conf/XEN (working copy) @@ -7,7 +7,7 @@ cpu I686_CPU ident XEN makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols -makeoptions WITHOUT_MODULES="aha ahb amd cxgb dpt drm drm2 hptnr hptmv ida malo mps mwl nve rdma sound sym trm xfs" +makeoptions WITHOUT_MODULES="aha ahb amd ctl cxgb dpt drm drm2 hptnr hptmv ida malo mps mwl nve rdma sound sym trm xfs" options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption Index: modules/Makefile =================================================================== --- modules/Makefile (revision 253803) +++ modules/Makefile (working copy) @@ -76,6 +76,7 @@ SUBDIR= \ ${_cryptodev} \ ${_cs} \ ${_ctau} \ + ctl \ ${_cxgb} \ cxgbe \ ${_cyclic} \