Problem

The vfile KFS driver is DAL E.
Customers want a high DAL uniform interface to files, devices, filesystem objects; wish to use vfile for this.
- This includes accessing files in the KFS (LFS or MFSes) using the vfile KFS driver.
- Can't - see 1.

Proposal

vfile XSD will allow the specification of content delivery via a child element of inodes that specifies the path to a host-local file.
vfileconfig will process any content delivery specifications into the binary configuration file, copying the host-local file content into the binary, and linking it to the inode in which it is specified.
vfileconfig should detect/collapse duplicate file references to save space.
vfile will provide a content delivery driver that knows how to fetch the file content from the configuration binary and provide it to the user via the usual vfile user APIs.
The access will, for now, perhaps forever, be read-only.

Add /etc path to standard vfile filesystem hierarchy and XML.
Add <content path=""/> element to vfile XSD as child element of <inode/>.
Update vfileconfig to add the content of specified files in <content/> elements to the output binary config file.
Add /etc built-in driver to vfile that provides standard access to the files added in /etc.
- During initialization vfile would add this driver's device operations to any file inside /etc.
- Directory hierarchy is automatically supported by built-in iterators.

The content delivery shouldn't be limited to just /etc. /etc will be added as a convenience path for such typical read-only configuration files. But content could theoretically be provided anywhere.
Could support decompression-read via zlibdev, if there is a concern that the delivered content is large. This means a dependency on zlibdev (and deos-zlib).
For CVT and for user "convenience", the binary configuration file could maintain a CRC or stronger security mechanism to ensure the file content is the expected file content.

Pro: Access to these files *only* require vfile, no additional driver since driver is built-in to libvfile.so.
Pro: File content is available always since these files are not subject to VFILE_AUTOLOAD.
Pro: KFS driver can remain read/write and DAL E.
Pro: Can effortlessly support mmap; files are already mapped inside the config.vfile.bcfg in every vfile-using process.
Pro: mapViewOfKernelFile -> open/mmap.
Pro: Capabilities are extendible with vfile XML schema updates.
Pro?: Can add more-secure image verification mechanism (md5? signed?)
Con: Adding files requires vfile XML; can't just add the file to the load list.
Con: Path to files is problematic. Adding a from /desk/ works. But adding a file from a relative path - not so much.
Con?: Not writeable.
Con: Need to update existing lower-DAL things, like lwIP, that might someday grow up to higher DAL things, to use these files instead of KFS. John already udpated lwIP to use vfile KFS driver to access lwip.config. Should be as simple as changing paths: /kfs/lwip.config -> /etc/lwip.config (and adding a vfile XML to lwIP to deliver /etc/lwip.config). However, without a way to use cdproc to figure out which lwip.config to pick from the DESK, and needing to use absolute path, might be a deal breaker.