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

[Edward Tomasz Napierała]

Wiadomość napisana przez Marius Strobl <marius at alchemy.franken.de> 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 <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 ...

Damn.  Now that you mention it... yeah, it was me who disconnected it,
in r249530.  I had no idea what's going on either.