svn commit: r249410 - in head/sys: amd64/conf arm/conf cam/ctl conf i386/conf ia64/conf modules/ctl sparc64/conf

[Marius Strobl]

On Tue, Jul 30, 2013 at 09:57:21PM +0200, Edward Tomasz Napiera?a wrote:
> Wiadomo?? napisana przez Marius Strobl <marius at alchemy.franken.de> 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 ...

Marius