CTF patch for testing/review

[Alexander Leidinger]

Quoting John Baldwin <jhb at freebsd.org> (from Tue, 23 Mar 2010 10:25:55 -0400):

> On Tuesday 23 March 2010 6:12:43 am Alexander Leidinger wrote:
>> Quoting "M. Warner Losh" <imp at bsdimp.com> (from Mon, 22 Mar 2010
>> 20:35:53 -0600 (MDT)):
>>
>> > In message: <201003221605.24538.jhb at freebsd.org>
>> >             John Baldwin <jhb at FreeBSD.org> writes:
>> > : On Monday 22 March 2010 3:05:12 pm M. Warner Losh wrote:
>> > : > In message: <20100322.125937.278730673160410010.imp at bsdimp.com>
>> > : >             M. Warner Losh <imp at bsdimp.com> writes:
>> > : > : In message: <20100322172104.14234yawbsev0sw8 at webmail.leidinger.net>
>> > : > :             Alexander Leidinger <Alexander at Leidinger.net> writes:
>> > : > : : Normally we use MK_xxx for things which are opt-in/opt-out.
>> > What about
>> > : > : : using MK_xxx instead of ENABLE_CTF? If people are in favour
>> > of MK_xxx,
>> > : > : : what should the xxx part look like?
>> > : > :
>> > : > : Normally we *TEST* MK_XXX for things which are opt-in/opt-out and
>> > : > : require the user to say WITH_XXX or WITHOUT_XXX if they don't like
> the
>> > : > : default (or want to ensure they get option XXX, even if we turn it
> off
>> > : > : by default in the future).  The default then gets encoded in
>> > : > : bsd.own.mk, and permeates the FreeBSD build system since we include
>> > : > : that everywhere, directly or indirectly.
>> > : > :
>> > : > : The problem is that bsd.own.mk is not included in sys.mk, nor should
>> > : > : it be.  That's why we have the hacky combination of WITH_CTF and
>> > : > : NO_CTF that's there today.
>> > : > :
>> > : > : : Is bsd.kern.mk included in module builds too?
>> > : > :
>> > : > : Yes.
>> > : >
>> > : > One last thing I should have said was that the patch that was posted
>> > : > earlier in the thread looked ok, and likely couldn't be made
>> > : > significantly better due to the bsd.own.mk issue.
>> > :
>> > : I think the patch is a good approach, I just think it needs to
>> > default to not
>> > : enabling CTF by default.  Instead, various bsd.foo.mk should selectively
>> > : enable it.
>> >
>> > I should have added that bit as well...
>>
>> And here it is:
>>    http://www.leidinger.net/test/ctf2.diff
>>
>> Please pay attention to one XXX comment. Both cases I describe look
>> possible, but I would like to get some more eyes on this issues to not
>> overlook something.
>
> I would maybe put a comment in front of the CFLAGS+= line for now and leave
> the rest of the XXX comment.  I'm not sure of the best way to solve this yet.

Done. I want to have a look if it is possible to do it similar to the  
LD_CTF_FLAG way later.

Currently I have the problem that WITH_CTF is not picked up by kmod.mk  
if "makeoptions WITH_CTF=yes" is used in the kernel config. This means  
that all makeoptions do not propagate to module builds.

Any ideas?

Maybe letting makeoptions add lines like "KERNELSUBMAKEARGS+=<content  
of makeoptions>" and using this for calls to make (I assume kernel  
modules are build by issuing calls to make in the corresponding  
directories)?

>> I haven't renamed the NO_CTF part yet. Bikeshed: ENABLE_CTF / ADD_CTF
>> / MK_CTF / MK_CTFINFO / MK_CTFINC / ...? Cast your vote please.
>
> I think the naming stuff you have used is fine.  I think it is better to use
> NO_CTF rather than MK_CTF because this is not set via bsd.own.mk but is a
> special case.

I agree.

Bye,
Alexander.

-- 
If graphics hackers are so smart,
why can't they get the bugs out of fresh paint?

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137