> Can anyone briefly explain to me what it means to have an integrated
> buffer cache

Basically, there are two ways a user might refer to data sitting in a
filesystem: through the user's address space (via mmap() or exec()),
or through read() and write().

On top of that, memory is also used for program data, which might be
swapped out to disk.  And you may also be caching data read directly
from a raw device.

Having an integrated buffer cache generally means having one pool of
memory pages for both virtual memory and filesystem data, and indexing
it several ways.  (You may also want to integrate cached data from raw
devices, but that sometimes gets left out of the picture.)

Right now, NetBSD has separate caches for virtual memory (things
referenced through a process's address space) and filesystem data.  In
addition to being inefficient at times, this means that an mmap()'d
region isn't always consistent with what's in the filesystem according
to read() and write().

(NetBSD also has a couple of bugs in its VM system which make it more
likely for mmap()'d data to be inconsistent with the filesystem.  I
tried to fix those a while ago, but my proposed fix caused deadlocks.)

> and what issues there are in implementing one (if we don't already
> have it).

How to look up appropriate parts of the buffer cache efficiently; how
to decide how much memory to use for swap space and how much to use
for caching filesystem data.