summaryrefslogtreecommitdiffstats
path: root/sys/conf/kern.pre.mk
Commit message (Collapse)AuthorAgeFilesLines
* Delete the old USB stack. The new stack has settled in and has all thethompsa2009-05-271-5/+1
| | | | drivers/functionality and then some.
* Allow the old usb stack to compile by adding the appropriate -I foo, this mustthompsa2009-02-261-1/+5
| | | | | | | | go before the standard -I$S to have the search happen before /sys/. Make this conditional on 'makeoptions WITH_LEGACY=1' in the kernel config. Prodded by: sam
* Revert previous change, since revision 187103 fixed the problem.rodrigc2009-01-151-2/+2
| | | | | | | | | | | | | So now, if you: - specify "makeoptions DEBUG=-g" in your kernel config - make buildkernel WITH_CTF=1, then "-g" will be added to CTFFLAGS. However, "-g" will still not be added to CTFFLAGS when building kernel modules, if the above steps are performed. This needs to be fixed. Noticed by: thompsa
* When building up the command-line for the DTrace ctfmerge and ctfconvertrodrigc2009-01-151-2/+2
| | | | | | | | | | | utilities, add the ${DEBUG} variable from the kernel config. Otherwise, if we build a kernel with WITH_CTF=1 set, ctfmerge will not have the -g flag set. In this case, the cc has -g specified, so the .o files will have debug information generated, but since ctfmerge does not have -g set, it will strip out the ELF sections containing the DWARF debugging info, leading to a kernel without debugging symbols. Reviewed by: jb
* Fix CTF based builds to that if the debug build is being used we getgnn2009-01-121-0/+1
| | | | | | debug symbols. Reviewed by: jhb
* Switch to ath hal source code. Note this removes the ath_halsam2008-12-011-2/+2
| | | | | | | | | | | | | | | | | module; the ath module now brings in the hal support. Kernel config files are almost backwards compatible; supplying device ath_hal gives you the same chip support that the binary hal did but you must also include options AH_SUPPORT_AR5416 to enable the extended format descriptors used by 11n parts. It is now possible to control the chip support included in a build by specifying exactly which chips are to be supported in the config file; consult ath_hal(4) for information.
* Update cxgb include paths to not require prefixing with dev/cxgbkmacy2008-09-231-0/+3
| | | | Submitted by: Chelsio Inc.
* Enable GCC stack protection (aka Propolice) for userland:ru2008-06-251-4/+1
| | | | | | | | | | | | | | | | | | | | | - It is opt-out for now so as to give it maximum testing, but it may be turned opt-in for stable branches depending on the consensus. You can turn it off with WITHOUT_SSP. - WITHOUT_SSP was previously used to disable the build of GNU libssp. It is harmless to steal the knob as SSP symbols have been provided by libc for a long time, GNU libssp should not have been much used. - SSP is disabled in a few corners such as system bootstrap programs (sys/boot), process bootstrap code (rtld, csu) and SSP symbols themselves. - It should be safe to use -fstack-protector-all to build world, however libc will be automatically downgraded to -fstack-protector because it breaks rtld otherwise. - This option is unavailable on ia64. Enable GCC stack protection (aka Propolice) for kernel: - It is opt-out for now so as to give it maximum testing. - Do not compile your kernel with -fstack-protector-all, it won't work. Submitted by: Jeremie Le Hen <jeremie@le-hen.org>
* Remove some sparc-specific stuff from my earlier sun4v work in p4.jb2008-06-091-2/+0
| | | | | | It never belonged in current. Pointed out by: marius
* Add support for generating CTF data for the kernel.jb2008-05-231-0/+15
|
* pc98 lint builds w/o warnings. Remove the last special case from ourimp2008-02-021-2/+0
| | | | | | compiler upgrade. # if tinderbox breaks, I'll fix it, but it shouldn't...
* Arm should build fine with -Werror as well.cognet2008-02-021-1/+1
|
* sun4v has a MACHINE_ARCH of sparc64, so it was covered under that clause andimp2008-02-021-1/+1
| | | | shouldn't have been added. Remove it.
* Some platforms that are currently under development have to cope withimp2008-02-021-2/+4
| | | | | | | | a variety of bootloaders. This sometimes means that different loader scripts are required within one ${MACHINE_ARCH}, which makes the current practice of using ldscript.${MACHINE_ARCH} unsuitable. Instead, make the default the current convention and allow the ld scripts to be overridden as necessary.
* Wall of shame rather than wall of fame for the -Werror suppression.imp2008-02-021-3/+1
| | | | | | | If we aren't arm, pc98 or sun4v, then enable treating warnings like errors. That doesn't mean these platforms aren't -Werror clean, just that we haven't enforced it before. Someone with some spare time should investigate these three platforms to see if any can be removed.
* Re-enable -Werror for PowerPC. This should really be unconditional again.marcel2007-08-081-1/+2
| | | | Approved by: re (blanket)
* Enable -Werror for ia64.marcel2007-07-311-1/+1
| | | | Approved by: re (blanket)
* Removed unnecessary global includes for ixgbe, and em. Both have beenjfv2007-07-121-6/+0
| | | | | | determined to be unnecessary. Approved by: re
* New driver for Intel 10G PCI-Express adapter (82598), driver isjfv2007-07-111-0/+3
| | | | | | | still in Beta, but we want early users to have access to it in 7.0, Feedback welcome. Enjoy. -Jack Approved by: re
* I did not intend to turn -Werror on for pc98. Refine the test forpeter2007-07-061-1/+1
| | | | | | turning it on for i386. Approved by: re (rwatson, followup)
* Turn on -Werror for sparc64 and sun4v.peter2007-07-061-1/+2
| | | | Approved by: re (rwatson)
* Turn on -Werror for i386 kernel builds.peter2007-07-051-1/+1
| | | | Approved by: re (rwatson)
* Turn -Werror back on for amd64 for kernel builds.peter2007-07-051-0/+2
| | | | Approved by: re (rwatson)
* Compile pf/pf_subr.c and netnatm/cc_conn.c without -Werror for the timepeter2007-07-051-1/+1
| | | | | | being. Approved by: re (rwatson)
* Disable -Werror for now.kan2007-05-191-2/+2
| | | | Remove -I- construct obsolete in GCC 4.2.
* Merge in the new driver (6.5.0) of Intel. This has a newjfv2007-05-041-0/+3
| | | | | | | | | | | | | | | | shared code infrastructure that is family specific and modular. There is also support for our latest gigabit nic, the 82575 that is MSI/X and multiqueue capable. The new shared code changes some interfaces to the core code but testing at Intel has been going on for months, it is fairly stable. I have attempted to be careful in retaining any fixes that CURRENT had and we did not, I apologize in advance if any thing gets clobbered, I'm sure I'll hear about it :) Approved by pdeuskar
* Fixed high resolution profiling on arches that support it (amd64 andbde2006-10-261-1/+1
| | | | | | | | | | | | | | | i386). Use -mprofiler-epilogue again, and don't use -finstrument-functions. The former has been fixed for arches that implement high-res profiling, and the latter has been useless for kernel profiling since gcc-3.4 when it started forcing -fno-inline. -fno-inline gives a kernel with performance characteristics too different from a normal kernel to be worth profiling, by turning off inlining of all the little optimized functions in headers. This interacts especially badly with FreeBSD's use of "static inline" for all inlines in headers, by creating many separate copies of the little functions, so not inlining tends to increase cache pressure where it should reduce it, and (since gprof(1) doesn't understand the copies) the statistics for the little functions are hard to interpret even if you want them.
* Reduced the ifdef tangle for profiling by moving the unreachablebde2006-10-261-12/+2
| | | | | | never-working parts for icc to the attic. Fixed some nearby style bugs.
* Define an empty C_DIALECT in case of "icc", just in case.ru2006-10-131-0/+1
|
* o move ath hal os glue code from the hal to the driver: this code wassam2006-09-181-1/+1
| | | | | | | | | | | | part of the hal distribution early on when the hal was built for each os but it's been portable for a long time so move the os-specific code out (and off the vendor branch) o correct the copyright on ah_osdep.?; it was mistakenly given a restricted license and not a dual-bsd/gpl license o remove the module api definition as it was never used o fixup include paths for move of ah_osdep.h MFC after: 2 weeks
* nuke unused support for building ath hal from src codesam2006-09-181-6/+0
| | | | MFC after: 1 week
* /etc/src.conf wasn't visable for the kernel build.obrien2006-07-171-0/+5
|
* Create new dialect knob, as setting the language dialect isn't a warning flag.obrien2006-06-291-1/+2
|
* Hook XFS into kernel build.rodrigc2005-12-121-0/+3
|
* We no longer need INCLUDES+= -I$S/contrib/dev/acpica.obrien2005-10-241-5/+2
|
* Define HAVE_KERNEL_OPTION_HEADERS when building kernel and when buildingglebius2005-10-051-1/+1
| | | | | | | | | | modules along with kernel. After this change it is possible to embrace opt_*.h includes with ifdef HAVE_KERNEL_OPTION_HEADERS. And thus, avoid editing a lot of Makefiles in modules directory each time we introduce a new opt_xxx.h. Requested by: bde
* The kernel-depend target doesn't get any information from "compile-with",obrien2005-09-111-0/+19
| | | | so repeat the includes paths for that target.
* Don't pollute the entire kernel build with -I$S/contrib/dev/ath andobrien2005-09-111-2/+5
| | | | | -I$S/contrib/dev/ath/freebsd. "ATH_BUILDING_FROM_SOURCE" can be defined to globally get back -I$S/contrib/dev/ath.
* Don't pollute the entire kernel build with -I$S/contrib/ipfilter.obrien2005-09-111-3/+0
|
* Don't pollute the entire kernel build with -I$S/contrib/pf.obrien2005-09-111-3/+0
|
* Don't pollute the entire kernel build with -I$S/contrib/ngatm.obrien2005-09-111-3/+0
|
* Don't pollute the entire kernel build with -I$S/dev/twa.obrien2005-09-111-3/+0
|
* Never hardcode /sys into these Makefiles. The proper way to spell it is $S.imp2005-04-131-0/+3
| | | | | | | Also, move the -I stuff to the centralized kern.pre.mk. However, it might be better to add these flags to files.conf. This is a short term fix to fix the broken builds on my machine (I don't have a valid /sys link).
* Don't generate major.c anymore.phk2005-03-291-1/+1
|
* Barrow from kmod.mk and protect against adding -fno-strict-aliasingobrien2005-02-131-1/+1
| | | | when it is already in COPTFLAGS.
* Embellish rev 1.61. If we're not building a debug kernel, use -O2 as before.obrien2005-01-221-2/+7
| | | | Submitted by: ru
* While we're building kernels -g (ie, makeoptions DEBUG=-g), use -O as itobrien2005-01-181-1/+1
| | | | | | | | | | provides truer debugger stack traces. For those that want to stick with -O2 kernel builds, one should probably add -fno-optimize-sibling-calls so that each stack frame as a frame pointer. It is semi-promissed by the Release Engineers that when RELENG_6 is created we go back to -O2. Desired by: scottl, jhb
* Don the teflon coated jacket and use the same -O2 optimization options onobrien2004-10-251-7/+1
| | | | the 'i386' kernel that we do all our 64-bit kernels.
* Back out v1.58... We still don't know what is causing the specifickensmith2004-10-071-1/+1
| | | | | | | | | | problem I had but it's happening in code that is messing around with register windows - I'm willing to live with that piece being sensitive to this and it looks like the other problems we had reported lately are not fixed by using -O instead of -O2. Sorry for the churn. Looks like I need a second pointy hat. Someone tells me they stack well. :-))))
* Back out v1.49. Recent findings suggest sparc64 may not be ready forkensmith2004-10-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | -O2 on kernel compiles after all. While working on adding a KASSERT to sparc64/sparc64/rwindow.c I found that it was "position sensitive", putting it above a call to flushw() instead of below caused corruption of processes on the system. jake and jhb have both confirmed there is no obvious explanation for that. The exact same kernel code does not have the process corruption problem if compiled with -O instead of -O2. There have been signs of similar issues floated on the sparc64@ mailing list, lets see if this helps make them go away. Note this isn't an optimal fix as far as the file format goes, if this disgusts too many people I'll fix it the right way. Since compiling with something other than -O is a known problem this format would prevent a change to the default causing grief. And this may also help motivate finding out what the compiler is doing wrong so we can shift back to using -O2. :-) My turn for the pointy hat... One of the florescent ones... MFC after: 2 days
OpenPOWER on IntegriCloud