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.
uncovering some interesting problems. Be conservative and effecitvely
disable this by default. Interested parties may still define
KERNBUILDDIR by hand to achive the same effect.
I plan on referting this change after 5.2 is released, or sooner if
the issues with building releases are resolved and re@ approves.
Approved by: re@ (scottl, marcel)
kernel build. This makes it possible for me not to get pissed off that
random.ko crashes the system trying to rdtsc() when the i386/cpu.h
support code decides it's okay to call that op when neither I386_CPU or
I486_CPU is defined. I guess it also makes WITNESS/INVARIANTS defines
get picked up by the modules.
no matter where in the directory structure it may be. Use this and the "-k"
flag in the generated gdbinit files so that the "getsyms" function in gdb
requires no user intervention to run and will find every module if they're
in the kernel build's module directory. This is still quite useful for
cases where gdb knows that the path for some modules is /boot/kernel and
others are in the object directory for /usr/src/sys/$ARCH/compile/kernel.
Approved by: grog
Always use sys/conf/kern.mk when building kernel/modules.
<bsd.kern.mk> is only preserved for sys/boot/pc98/boot2
for now, but this will be fixed. If there are other
users of <bsd.kern.mk>, please let me know.
Reminded by: bde
is a compiler tool and needs to be compiled by the host compiler. I've
tested this in i386->sparc cross-build, 4.7->current upgrade, normal
buildkernel target, and normal /sys/i386/compile/GENERIC configurations.
Submitted by: ru
under way to move the remnants of the a.out toolchain to ports. As the
comment in src/Makefile said, this stuff is deprecated and one should not
expect this to remain beyond 4.0-REL. It has already lasted WAY beyond
that.
Notable exceptions:
gcc - I have not touched the a.out generation stuff there.
ldd/ldconfig - still have some code to interface with a.out rtld.
old as/ld/etc - I have not removed these yet, pending their move to ports.
some includes - necessary for ldd/ldconfig for now.
Tested on: i386 (extensively), alpha
the environment for the last command of the pipeline (xargs) instead
of too early in the broken version or using an extra env process for
each command spawned by xargs as in rev.1.12. Fixed a nearby English
error.
-finstrument-functions instead of -mprofiler-epilogue. The former
works essentially the same as the latter but has a higher overhead
(about 22 more bytes per function for passing unused args to the
profiling functions).
Removed all traces of the IDENT Makefile variable, which had been
reduced to just a place for holding profiling's contribution to CFLAGS
(the IDENT that gives the kernel identity was renamed to KERN_IDENT).
to build kernel and kernel modules so stop supporting them in
bsd.subdir.mk and reimplement them in kern.post.mk and kmod.mk
as special versions of the install and reinstall targets, and
only define them if DEBUG is also defined (when debug versions
are really built).
Prompted by: bde
"env name=value ... cmd ..." is just a pessimized way of doing
"name=value ... cmd ..." in real shells. Set the environment
(without using env(1)) before starting xargs so that env(1)
is not needed in "xargs env name=value ... cmd ..."
lint, so this is turned off by default. Setting WANT_LINT will turn
on generation of lint libraries for /usr/libdata/lint/*.ln.
Reviewd by: silence in -audit.
so that this is safe even if VARIABLE is longer than kern.argmax.
There is another instance of CFILES which might need the same treatment,
and might be noticed when doing a "make links".
The same has to be done in RELENG_4 (on some different file).
Noticed-by: picobsd cross-compiling LINT
Suggested-by: Alfred (bright@mu.org), des@freebsd.org
MFC-after: 3 days
simplifying the module linking process and eliminating the risks
associated with doubly-defined variables.
Cases where commons were legitimately used (detection of
compiled-in subsystems) have been converted to use sysinits, and
any new code should use this or an equivalent practice as a
matter of course.
Modules can override this behaviour by substituting -fno-common
out of ${CFLAGS} in cases where commons are necessary
(eg. third-party object modules). Commons will be resolved and
allocated space when the kld is linked as part of the module
build process, so they will not pose a risk to the kernel or
other modules.
Provide a mechanism for controlling the export of symbols from
the module namespace. The EXPORT_SYMS variable may be set in the
Makefile to NO (export no symbols), a list of symbols to export,
or the name of a file containing a newline-seperated list of
symbols to be exported. Non-exported symbols are converted to
local symbols. If EXPORT_SYMS is not set, all global symbols are
currently exported. This behaviour is expected to change (to
exporting no symbols) once modules have been converted.
Reviewed by: peter (in principle)
Obtained from: green (kmod_syms.awk)
kern.post.mk.
# this should allow us to move kern.post.mk to the last line of the makefiles,
# but I'll do that slowly as I verify that one can do that w/o breaking things.
Submitted by: naddy
Fix it by putting back the link of machine to sys/i386/include rather
than ../../include (aka sys/pc98/include). I had a stale machine link
on my first test.
Not sure what the "right" fix is, but this unbreaks things.
new files: kern.pre.mk, which contains most of the definitions, and
kern.post.mk, which contains most of the rules.
I've tested this on i386 and pc98. I have had feedback on the sparc64
port, but no reports from anybody on alpha, ia64 or powerpc. I
appologize in advance if I've broken you.
Reviewed by: jake, jhb, arch@
