to amd64, i386, and pc98. The headers are installed to /usr/include/x86
during an installworld, and an 'x86' symlink is created for kernel builds
similar to 'machine' so that the headers can be included as <x86/foo.h>.
Reviewed by: imp
are some problems with static executables), make.conf (would also
affect ports which do not use GNU make and do not override the
compile targets) or in the kernel config (via "makeoptions
WITH_CTF=yes").
Additional (related) changes:
- propagate WITH_CTF to module builds
- do not add -g to the linker flags, it's a noop there anyway
(at least according to the man page of ld)
- do not add -g to CFLAGS unconditionally
we need to have a look if it is really needed (IMO not) or if there
is a way to add it only when WITH_CTF is used
Note: ctfconvert / ctfmerge lines will not appear in the build output,
to protect the innocent (those which do not build with WITH_CTF would
see the shell-test and may think WITH_CTF is used).
Reviewed by: imp, jhb, scottl (earlier version)
Discussed on: arch@
to module builds. This avoids having to have the module builds walk up
the tree to find the kernel sources. It also allows a kernel + module
build to succeed when a new level of module subdirectories is added without
requiring that the /usr/share/mk/bsd.kmod.mk file on the machine be patched.
MFC after: 1 week
installing the kernel allows one, like with modules, to override
the default user/group and install as non-su to a temporary
directory to test, create images or seed a tftp dir.
Reviewed by: Andrzej Tobola <ato@iem.pw.edu.pl>
MFC after: 4 weeks
This allows to fix a problem with ARM kernel.bin not having the MFS image
embedded: it is objcopied from the kernel.noheader temporary ELF file, which
was not subject to embedding the MFS image previously.
Reviewed by: imp
Approved by: cognet (mentor)
for those upgrading from 4.x -> 5.x. It is therefore no longer
necessary because it is installed on 5.x and 6.x and one has to
upgrade from 6.x -> current, or at the very least 5.x (although not
supported, it can be made to work).
only now) symbolic links in the kernel compile directory, rather
than relying on config(8) to do this. (The changes to config(8)
will be committed separately.) This is aimed towards making the
config(8) as lightweight as possible.
Idea by: bde (all bugs are mine)
gdb(1) command better, though I must admit it's confusing: these
files have not only [debugging] symbols, but much more than that.
Requested by: obrien
our kernel linker will only load PT_LOAD segments, apparently not.
Instead, produce .dbg objects from .debug objects, and install
them together with non-debug objects, as described in objcopy(1).
Original code by: obrien
Try to make everyone happy: David (to have debug kernels installed
by default), Warner (to be able to override that), and myself (for
actually making it all work and to be consistent).
Now, if kernel was configured for debugging (through DEBUG=-g in
the kernel config file or "config -g"), doing "make install" will
install debug versions of kernel and module objects with their
canonical names,
kernel.debug -> /boot/kernel/kernel
if_fxp.ko.debug -> /boot/kernel/if_fxp.ko
Installing a kernel not configured for debugging, or debug kernel
with INSTALL_NODEBUG variable defined, will install non-debug
kernel and module objects.
Also, restore the install.debug and reinstall.debug targets that
are part of the existing API (they cause some additional gdb(1)
scripts to be installed).
be installed. It should have been optional to install a non-debug
one, just like it was formerly optional to install a debug one. In
order to do that, most of 1.84 had to go.
Instead, make installing the debug kernel the default, but create a
new option INSTALL_NODEBUG for those people that have small /
partitions and good source control habits.
This preserves the behavior of 1.84 while allowing it to be overriden
for people (like me) that do not have the time to upgrade to get a
bigger / and also don't have time for stupid makefile tricks when
upgrading their older system, but still want a kernel.debug around if
things go south.
initializations but we did have lofty goals and big ideals.
Adjust to more contemporary circumstances and gain type checking.
Replace the entire vop_t frobbing thing with properly typed
structures. The only casualty is that we can not add a new
VOP_ method with a loadable module. History has not given
us reason to belive this would ever be feasible in the the
first place.
Eliminate in toto VOCALL(), vop_t, VNODEOP_SET() etc.
Give coda correct prototypes and function definitions for
all vop_()s.
Generate a bit more data from the vnode_if.src file: a
struct vop_vector and protype typedefs for all vop methods.
Add a new vop_bypass() and make vop_default be a pointer
to another struct vop_vector.
Remove a lot of vfs_init since vop_vector is ready to use
from the compiler.
Cast various vop_mumble() to void * with uppercase name,
for instance VOP_PANIC, VOP_NULL etc.
Implement VCALL() by making vdesc_offset the offsetof() the
relevant function pointer in vop_vector. This is disgusting
but since the code is generated by a script comparatively
safe. The alternative for nullfs etc. would be much worse.
Fix up all vnode method vectors to remove casts so they
become typesafe. (The bulk of this is generated by scripts)
Users should move to the new geom_vinum implementation instead.
The refcount logic which is being added to devices to enable safe module
unloading and the buf/vm work also in progress would require a major rework
of the (old)-vinum code to comply with the new semantics.
The actual source files will not be removed until I have coordinated with
the geomvinum people if they need any bits repo-copied etc.
This is necessary so source upgrades use the correct binary.
MFC after: 3 days
For the record: Problem spotted by Scott Long, who mentioned
that source upgrades from 4.7 to recent 5.x and 6.0 are broken.
Detailed analysis shows that 4.7 has a broken make(1) binary.
A breakage was fixed in RELENG_4 in make/main.c,v 1.35.2.7 by
imp@, though the commit log erroneously stated "MFC 1.68"
while in fact it should have been spelled as "MFC 1.67".
Now that the devs files are marked before-depend, we can remvoe them
from a few places they were explicitly mentioned (along with
BEFORE_DEPEND).
Noticed by: bde
delete it each time its run and have it regenerated each time by make.
I used a quick hackish script rather than putting it in the files file
and used the before-depend rule to avoid the depend/no-depend hacks.
