- fix emitrules() like emitfiles() to deal with the prefix (otherwise it
would attempt to find the file in the normal base for the NORMAL_C rule).
- add emitincludes() which adds include directives for each prefix to the
$INCLUDES variable in the makefile.
- add %INCLUDES to each Makefile.arch to deal with the above.
this makes "prefix" actually work in a usable manner, and now i can move
on to fixing compiler warnings (errors) in the ESP code. :)
to file specifications. The prefixes are arranged in a stack, and
nest, so that file, object, and include specifications are normalized,
and all end up relative to the kernel compile directory.
For example, in the kernel config file:
# Pull in config fragments for kernel crypto
prefix ../crypto-us/sys # push it
cinclude "conf/files.crypto-us" # include it if it's there
prefix # pop it
and in files.crypto-us:
file netinet6/esp_core.c ipsec & ipsec_esp
file netinet6/esp_output.c ipsec & ipsec_esp
file netinet6/esp_input.c ipsec & ipsec_esp
...generates the following in the kernel Makefile:
$S/../crypto-us/sys/netinet6/esp_core.c \
$S/../crypto-us/sys/netinet6/esp_output.c \
$S/../crypto-us/sys/netinet6/esp_input.c \
By placing this all in the kernel config file, all the magic involved in
reaching into non-standard kernel source directories is placed into a file
that the user is expected to edit anyway, and reasonable examples (and
sane defaults, for typical source checkouts) can be provided.
Update coda to new struct lock in struct vnode.
make fdescfs, kernfs, portalfs, and procfs actually lock their vnodes.
It's not that hard.
Make unionfs set v_vnlock = NULL so any overlayed fs will call its
VOP_LOCK.
the functionality of nullfs. The latter is now just a mount & unmount
routine, and a few tables. umapfs borrow most of this infrastructure.
Both fs's are now nfs-exportable.
All layered fs's share a common format to private mount & private
vnode structs (which a particular fs can extend).
Also add genfs_noerr_rele(), a vnode op which will vrele/vput
operand vnodes appropriately.
RAIDframe driver to stop it from eating too much kernel memory when
writing data. But that fix had a nasty side-affect of hurting write
performance (*much* more than I thought it would). These changes nuke
that "fix", and instead put in a more reasonable mechanism for limiting
the number of simultaneous IO's which can be happening for each RAID device.
The result is a noticeable improvement in write throughput. The End.
itojun