1. Removed the makeoptions line from arch/i386/conf/GENERIC. Now
ndis_driver_data.h is simply copied into the kernel build directory instead
of editing the config file to specify its location.
2. Uncommented lines in files.i386 and files.pci related to NDIS. NDIS will
not be compiled into the kernel unless the two lines are uncommented from
GENERIC (I checked using nm), so there is no reason for this to be commented
out.
3. Added ndiscvt to usr.sbin/Makefile.
backing file per attribute type indexed by inode number to hold the extended
attributes.
This is working pretty well on my test systems, except for the "autostart"
feature. I need someone with a better handle on the VFS locking protocol
to go over that.
This is a work-in-progress. There are parts of this that could be re-factored
allowing this approach to be used on other types of file systems.
Adapted from FreeBSD.
headers and LKM.
Add MKPF; if set to no, don't build and install the pf(4) programs,
headers, LKM and spamd.
Both options default to yes, so nothing changed in the default build.
Reviewed by lukem.
Uses a hook in spec_strategy() to save data written from a mounted
file system to its block device and a hook in dounmount().
Not enabled by default in any kernel config.
Approved by: Frank van der Linden <fvdl@netbsd.org>
two variables:
TOOLCHAIN_MISSING -- set to "yes" on platforms for which there is
no working in-tree toolchain (hppa, ns32k, sh5, x86_64).
EXTERNAL_TOOLCHAIN -- if defined by the user, points to the root of
an external toolchain (e.g. /usr/local/gnu). This enables the cross-build
framework even for TOOLCHAIN_MISSING platforms.
If TOOLCHAIN_MISSING is set to "yes", MKGDB, MKBFD, and MKGCC are all
unconditionally set to "no", since the bits are not there to build.
If EXTERNAL_TOOLCHAIN is set, MKGCC is unconditionally set to "no",
since the external toolchain's compiler is not in-sync with the
in-tree compiler support components (e.g. libgcc).
* Set MACHINE_CPU much earlier in bsd.own.mk, so that more tests in
that file can use it.
infrastructure and using that infrastructure in programs.
* MKHESIOD, MKKERBEROS, MKSKEY, and MKYP control building
of the infratsructure (libraries, support programs, etc.)
* USE_HESIOD, USE_KERBEROS, USE_SKEY, and USE_YP control
building of support for using the corresponding API
in various libraries/programs that can use it.
As discussed on tech-toolchain.
Only sun3[x] was building it anyway, and now it's converted to
USE_NEW_TOOLCHAIN, where all ports (will) have it. The other reason to
descend is the man page, but what use is a man page if the program
doesn't get installed? [gnu/usr.sbin/dbsym has its own copy of the
man page.]
Ok'd by thorpej.
rittera