The tux3 code is starting to get a little more interesting now.
Another significant part of the kernel vfs machinery is now emulated:
the page cache. Which in userland does not have to care about pages,
so it works in buffers instead, and instead of a special index field
we just reinterpret the block field as an index. This is the way the
Linux kernel does it anyway (actually I dimly recall that change came
about in Linux as a response to the way I handled directory block
access in htree) but this is obscured by the confusion between block
and page units of granularity. The kernel uses a page cache with a
direct device mapping to implement the buffer cache, while my code
uses the buffer cache to implement the equivalent of the kernel page
cache. The latter is a much cleaner way to do things, but is not an
option for the kernel until we get around to generalizing page size.
Anyway, both in kernel and in my emulation, the block interface is
just the vererable BSD standard getblk and bread, with writing done
by marking buffers dirty and flushing them out en mass periodically.
Easy to understand and get right.
This page cache emulation effort is about making directory operations
happen. We want to scan sequentially through an entire directory file
looking for an entry or a place to create a new one. So we need a
notion of what sequentially means. One way is to walk an inode btree,
but that is not the way the kernel does things, and that would be a
problem when it comes time to port. What the kernel does is read each
block of a directory file into a page cache the first time somebody
accesses it, and after that, the cached block can be accessed very
efficiently without needing to read it again or having to go messing
around in the filesystem metadata. This is really, really powerful.
You do not want to go trying to reimplement that kind of caching at
the filesystem level, because you will just end up with a lot of code
that does not do nearly as good a job as the kernel page...
