Description

This project is to create a Deos filesystem interface that would permit application defined filesystems that support ELF image loading, and ideally more general filesystems at some time in the future.

The first version of this page is a direct copy of the notes taken at GeekFest_2019.

Be A Maintainter

Use Cygwin Jupiter
install unreleased integ tool
rm /desk/*/etc/deos-kernel.fp.xml
Build and install mainline hypstart from head
Build and install experimental kernel from head

Open Arbor Approach

This puts a KFS image in the SCATHitmap resource on the platform.

Create hello world example
Add dependency to ansi
Replace hello-world.cpp with Save As this link to hello-world.cpp in your workspace

Upate hello-world.pd.xml:

mountQuota = "2"
         Within the process instance:
         Update fileSystemSearchPath to: fileSystemSearchPath = "/hello:/"
         Add:
         <ownedFileSystems>
            <ownedFileSystem
                 resourceName = "SCATHitmap"
               >
               <automount
                    mountPath = "/hello"
               ></automount>
            </ownedFileSystem>
         </ownedFileSystems>

Upate platreg.pi.xml: memoryMappedResource SCATHitmap,
```
allowMultipleOwners = "yes"
```
Update target load but DO NOT put hello-world.exe

Create a MFS image:

echo "This is t1.txt." > t1.txt
echo "This is t2.txt." > t2.txt
mkkfs.py -target=arm -kernelFile=hello-world.exe,/cygdrive/c/OpenArbor/workspace/.../hello-world/output/arm-eabi/diagnostic/hello-world.exe -kernelFile=t1.txt -kernelFile=t2.txt -output=kfs1.arm.mfs -storageBlockAddress=0x40004000

ppc:

mkkfs.py -target=ppc -kernelFile=hello-world.exe,/cygdrive/c/OpenArbor/workspace/.../hello-world/output/powerpc-motorola-elf/diagnostic/hello-world.exe -kernelFile=t1.txt -kernelFile=t2.txt -output=kfs1.ppc.mfs -storageBlockAddress=0x4000

For x86, the mkkfs.py command must be (the image is too large to include t1.txt):

mkkfs.py -target=x86 -kernelFile=hello-world.exe,/cygdrive/c/OpenArbor/workspace/.../hello-world/output/i686-pc-elf/diagnostic/hello-world.exe -kernelFile=t2.txt -output=kfs1.x86.mfs -storageBlockAddress=0x1f8000

Put the image on the target:

putapp kfs1.arm.mfs /proc/res/SCATHitmap

Well, you'd like that to work, but on some configurations (e.g., kernel debugger before doing an update target load) lwip doesn't "own" SCATHitmap, instead you must do:

arm/ppc: (0x4000 is the hex address of the SCATHitmap resource)
putapp kfs1.arm.mfs /proc/vm/0x4000
putapp kfs1.ppc.mfs /proc/vm/0x4000

x86:

putapp kfs1.x86.mfs /proc/vm/0x001f8000

For shell aficionados here are some helpful commands:

IP=192.168.19.103; mkkfs.py -target=arm -kernelFile=hello-world.exe,/cygdrive/c/OpenArbor/workspace/2018-jupiter-1/kernel/hello-world/output/arm-eabi/diagnostic/hello-world.exe -output=kfs1.arm.mfs  -kernelFile=t1.txt -kernelFile=t2.txt && tarattrib -targetIPAddr=$IP -downloadingPermitted=true DEOS && putapp -targetIPAddr=$IP kfs1.arm.mfs /proc/vm/0x4000 && tarattrib -targetIPAddr=$IP -downloadingPermitted=false DEOS

IP=192.168.19.100; mkkfs.py -target=x86 -kernelFile=hello-world.exe,/cygdrive/c/OpenArbor/workspace/2018-jupiter-1/kernel/hello-world/output/i686-pc-elf/diagnostic/hello-world.exe -output=kfs1.x86.mfs  -kernelFile=t2.txt && tarattrib -targetIPAddr=$IP -downloadingPermitted=true DEOS && putapp -targetIPAddr=$IP kfs1.x86.mfs /proc/vm/0x001f8000 && tarattrib -targetIPAddr=$IP -downloadingPermitted=false DEOS

Tasks

Multiple KFS

Customer: Durants3_Program
Task name: (F13) KFS Individual part number
Planned Completion: November 15, 2019 (Stable) Single digit priorities only.

Task	Priority	Status	Effort (hours)	Remarks
Implement/?? mfs_checkFileIntegrity()	10	Deferred		Perhaps add an "unimplemented" status code?
Finish KFS API/error issues for file operations	10	Deferred		What errors are defined at API level? What is mapping, etc. Consider reserving first TLS word as errnum basis, e.g., get/set thread error.
Update QEMU config components to support another KFS.	10	Deferred
Add version to kernel-integ-tool-if.py.	10	Deferred		Do this on mainline? Aaron with consult with GK.
What is 'spec language' for building BIF images?	10	Deferred		Command line is good enough for Nov 15
OpenArbor Integration	10	Pending		Add files to MFS. Put MFS to platform resource? Automounts for 653? Process specific directory list?
653 Integration	10	Test		Deos653config 1.22.0 unreleased, works with IT 3.45.0 as of 11/30. Supports automount, paths. Includes MMS-to-WAT reference checks as requested on support.
Deos-POSIX Integration	10	Pending		Automounts for Deos-POSIX?
System level MFS mounts	99	Deferred		Not going to happen until customer funded.
		Total	@sum(column)

Driving Use Cases

Special Binary

The "special binary" request from Durants3_Program:

Application dynamically programmed RAM that can reference libraries from the kfs (or at least currently loaded libraries in the process). For example, the application would decrypt a filesystem into a volatile RAM to ensure the decrypted program never lives in non-volatile RAM, and probably ideally would never be visible off chip.

Individual Part Numbers

Request from Durants3_Program:

FLASH region/area that that contains one or more ELF shared object files that can be independently "flash loaded", then at runtime loadLibraryDeos() loaded.
- Each perhaps needing different versions of things like ANSI.

Proposal

Introduce the capability for a process to access more than one filesystem. The existing Deos APIs to access kernel files will be usable across filesystems as described below.

The platform registry will contain a specification of the physical memory regions that contain filesystems. The region must be linear memory mappable. Whether the region corresponds to RAM or persistent memory is system configuration dependent.

The filesystem format is Deos proprietary, i.e., the "kernel filesystem" format. A host based tool, similar to hypstart, will be provided to create a filesystem image based on a set of files. A tool, similar to hypdump, will be provided to dump the contents of a filesystem.

The platform registry will specify the processes that can mount a given filesystem.

Mounting a filesystem makes the files in the filesystem visible to the process performing the mount. The accessibility of individual files is controlled by the access rights in the registry. Access rights are based on the file name, as was the case in prior versions of the kernel.

Mounting a filesystem causes all the files in the filesystem to appear in the "root" of the kernel filesystem. I.e., there are no directories.

Each process will contain a list of "automatically mounted" filesystems. These filesystems will be mounted before the process' executable is mapped.

Files with the same name may appear in different mounted filesystems. filesystems are searched in LIFO "mount" order.

A process can dynamically (pragmatically) mount any filesystem it has access to (this is to support the "special binary" use case).

The kernel assumes that the contents of a filesystem are valid. mounting an invalid filesystem could result in partitioning violations, e.g., a kernel crash.

If a process has access to the physical memory underlying a filesystem, i.e., by being granted access to a platform resource, the process must ensure that the filesystem contents remain valid when the filesystem is mounted.

Updating filesystems

The kernel will not contain any way to modify a filesystem.

A new library, libkfs.so, will be provided that permits individual file updates for the "main"/kfs0 filesystem, but only during development, and only if the filesystem is in simulated FLASH. The kfs library will be DAL E and require debug services honored.

To update secondary filesystems, the entire filesystem image must be put.

How filesystems are loaded onto the target is the responsibility of the platform provider. For development time activity the existing Deos ftpserver has infrastructure that supports updating platform resources, but if there is a special device write protocol, e.g., for FLASH, the platform provider must supply a device driver library.

Accomplishments to date

Created the KFS library.

Updated the boot visible image formats, including the hyperstart image, to support multiple filesystems.

Removed PAL FLASH interface functions.

Eliminated verification of free and fresh maps from the PIG.

Removed the following from kernel 9.0.0:

FLASH
APIs (and associated reqts and tests):
  saveKernelFile
  deleteKernelFile
  moveKernelFile
newSVAS
PIB/PVA update code.
portions of the VAS code
  makeFreezable
portions of FrozenVAS
spinlocks
some registry code associated with writable filesystem permissions
eliminated large portals which slightly simplified portal analysis
srt.{h,cpp}
srtiface.h

Internal Preliminary Design Notes

Names:

Kernel File System (KFS) Either of these
- Legacy File System (LFS) The FrozenVAS based file system used by hypstart
- Minimal File System (MFS) The new invention, "minimal" implies, e.g., usable by boot.

The choice of KFS is to note several different things, and to retain some semblance of backward compatibility for what KFS means to our users:

implemented by kernel.
loadable in kernel space. MFS not now, but eventually.

Simplified KFS Tasks

Random Notes

Schedule is tight. Here are some ideas to help:

Priority is ARM/PPC ELF format. x86 format can be slipped for Nov 15 due date if that helps meet schedule.
Can skip checkFileIntegrity for now.
This work will be carried out on mainline of hypstart, and experimental of kernel.
1. The belief is hypstart will be unchanged, so this will be strictly backward compatible w.r.t. hypstart
None of this requires future features.
Current (boot) image formats don't have a way to specify striping, that issue is deferred.
For checkKernelFileIntegrity
- need platform resource variant
- can return success for now.
- implement genericially, exception issue

KFS Format

Incomplete, but idea is:

KFS will be a BootImageFileHeader_t with three subsections, ref /desk/include/boot-image-file.h

First subsection is for future expansion as a header. Currently unused.
Second subsection is a "KFSDirectory_t".
1. The entries in the directory must be lexicographically ordered by file name.
2. The order of the file contents does not have to follow that ordering, but it probably makes user review of the dump easier if the directory and content order is consistent.
Third subsection is file data for the directory's files.

A "KFSDirectory_t" legacy definition is in https://ddci.zapto.org/scm/Deos/products/kernel/kernel/branches/experimental/code/kernfile/kfs-directory.h

Anticipated changes from what is in scm:

Where KFSDirEntry_t is slightly changed. Specifically vasPtr is replaced with "fileOffset", which is the page aligned offset (in bytes) from the beginning of the BootImageFileHeader_t of the start of the file.

By making PIB have a union for vasPtr and fileOffset, the directory manipulation routines should be able to share (most) code.

Kernel File System API

Philosophy: minimize APIs that deal with strings, use handles for as much as possible. The search path, when specified as handles, means no redundant directory searches.

Kernel file interfaces are suitable for read only file systems. Support for writeable file systems would come from some non-kernel interface layer. We might have to add some open/close like calls in loadLibraryDEOS at that time.

Documentation fodder

The kernel supports a hierarchical file system containing directories. Currently the only way to create a directory is via the "mount" command.

Services exist to convert between ASCII names and file handles, and to get information about a file handle, such as its name, its type (directory vs file), its siblings, and if it is a directory its children.

New (MFS) file system permits file systems to be mounted in platform resources...

Legacy behavior: Registry defines auto mounts and a search path used by loadLibraryDEOS and firstKernelFile(when pKey != 0). Other legacy APIs are largely restricted to the "root" directory.

fileHandle means something in a directory, it could be a file with content in the file system or a directory.

Suggest you don't use "/" in a file name.

Interface code

// A null terminated vector of pointers to character strings, e.g.,
// {"usr", "bin", "gcc", 0}
typedef filePath_t const char **;

// These are magic tokens used to refer to kernel internal data
// structures.  The tokens are not the actual data structures
#define useRegistrySearchPath       ((kernelFileHandle_t*)0)
#define useRegistrySearchPathLength (0)

Special file handles:
 - All mount points have a handle of the form: { scope=x, mount index=-1, fileID=mount index}
 - rootDirectoryHandle { scope=system, mount index=Fs, fileID=0}
 - No API/public symbol for the root directory, just document this equivalence:
   getKernelFileHandle({0}, &rootDirectoryHandle)

nextDirectoryEntry(rootDirectoryHandle) results in error
file name of rootDirectoryHandle is ""
  - To compute the "path name" e.g., "/dir1/dir2/file" of a file handle:
  - parent dir name + "/" + child dir name
  - Implication is that rootDirectory's name is ""

KerneFileStatus firstDirectoryEntry(dirHandle, kernelFileHandle_t*)
 - Returns the handle of the first child in that directory.
 - Need distinct status codes for invalid dirHandle, not a dir, and no children

KerneFileStatus nextDirectoryEntry(kernelFileHandle_t current, kernelFileHandle_t* next)
 - return file or "directory" handle, 
 - Need distinct status codes for invalid dirHandle, not a dir, and no children

KerneFileStatus findKernelFile(const char* name,
                               const kernelFileHandle_t *searchPath,
                               size_t searchPathLengh, 
                               kernelFileHandle_t*);
  - abstract pseudo-code (and ignoring error conditions)
    for sp in searchPath:
      if namedDirectoryEntry(dir, name) then return it
    retun "not found"


new API
kernelFileStat(stat, sizeof(stat), name, sizeof(name))

typedef int32_t kernelFileType_t;
enum {kernelFileRegularFile, kernelFileDirectory};

typedef struct
{ 
  /* Size of the file in bytes.  Undefined for directory. */
  size_t sizeInBytes;

  Fix this in PIB on mainline.
  /* See saveKernelFile() documentation */
  crc32_t integrityKey;

  /* See saveKernelFile() documentation */
  uint32_t userDefined1;

  kernelFileType_t type;

} kernelFilestat_t;


getKernelFileHandle(path_t path, &handle)
 - e.g., pathHandle({"desk", "bin", 0}, &deskBin)
 - path starts at root.
 - root is {0}
 - abstract pseudo-code (and ignoring error conditions)
   result = rootDirectoryHandle
   for subdir in path;
     if result not a directory, then return "not a dir"
     result = namedDirectoryEntry(result, subdir)
   return result;

kernelFileHandle_t = mount(kernelFileHandle_t <of directory containing the mount point>,
                           "name within the directory", 
                           "device/resource")
 - If name exists in directory then fails.
 - after each mount, updates handle vector associated with useRegistrySearchPath
 - mount table entry contains handle of "parent" directory where it is mounted.
 - mount data on the user stack must contain an array of
   kernelFileHandle_t of the same length as the registry search path,
   initialized to invalidKernelFileHandle {scope=user(1), mount index=-1, fileID=-1}

Deprecate the Following:
  Philosophy is they are largely unchanged because they would not know
  how to deal with directories that might be returned in a DEOS_PIB.
  Consequently DEOS_PIB is unchanged.

  firstKernelFile()
    when pkey != 0
      search search path, i.e., call findKernelFile, but consider
      directories as "not found".
    when pkey == 0
       only rootdirector/kfs0  (skip directory entries)
    This permits existing executables to nominally use new file
    systems semi-automatically, but only for "normal files".

  nextKernelFile()
    only works on "actual files" in kfs0

  kernelFileByHandle()
   - returns legacy DEOS_PIB info, but only for "normal" files, in
     either LFS or MFS.

API "changes"
  loadLibraryDEOS()
   - uses the registry specified path to find files
   - Perhaps add file handle to the objectFileRecord (for debugging)
  mapViewOfKernelFile()
   - Follows behavior of firstKernelFile.
  mapViewOfKernelFilePPI()
   - No changes now!
 
----------------------------------------
Non public info:

Registry specifies device/resource name and the directory where each
device (platform resource) will be mounted something like this:

 { "device name", "mount directory name", {"path", "to", "directory", 0}}
 { "efis filesystem", "data", {"projects", "efis", 0}} mounts "efis filesystem" as directory /projects/efis/data

kernelFileHandle_t = auto_mount("resource name", "place within file system", "name within place")

Helper for pseudo code
namedDirectoryEntry(dirHandle, const char* filename, kernelFileHandle_t *result)
 - e.g., namedDirectoryEntry(deskBin, "tardebug.py", &tarDebugHandle)
 - uses findNamedFile file system operation to search the dirHandle's
   directory for the given name, and also searches for mount points in
   that directory.

Deferred.
> We *could* complete the interface by defining "directory" nodes in LFS
> and MFS.
> 
> - mkmfs (and hypstart) have the ability to create "empty directory
>   nodes" which can only be used as mount points.

Mount Table Format

TBD. For notes see https://deos.ddci.com/mailman/private/kernel-maintainers/2019-November/001526.html

Current notes:

 status, handle = mount(file system type/operations, deviceName, mountPoint, access/options)

ops is the symbol we're goiung to export from the kernel containing the MFS file operations.
mountPoint is nominally the directory where the mount is placed:
- mountPoint parameter currently unused. Should be a unique name starting with a "/", or just "/". Convention is still TBD.
Only access option initially supported is "read only"

Platform Resource APIs

Need two new platform resource functions

mapViewOfPlatformResource

Modeled as much as possible after mapViewOfKernelFile, with the following changes:

platform resource name replaces fileName
desiredAccess must account for the fact that the resource might be writable (and hence sharable in write mode), where as kernel files were intrinsically read only
platform resource offset replaces fileOffset

The access granted and the required behavior depends on the access granted to the current process by the registry, and the access requested in the API call.

regDriver* access is not relevant.

If the current process does not have at least regUserReadBit access, then fail.

The resource must be regAddressSpaceMemory. Resource that would be proxy access should be refused, however what defines proxy access, the resource or the mapping range within the resource, is open (depends on effort). Specifically, if the resource attatch is to a part of a resource, and the resulting start and end addresses are aligned, then we

could* permit the access.

Here is the matrix for the remaining behavior (mapViewAccessTYP column the "mapView" prefix is removed):

 Registry specified   mapViewAccessTYP
 resource access      bits             result
 regUserReadBit       ReadWrite        fail
                      Read             mapped readonly
                      ReadWrite|Copy   writeable RAM copy
                      Read|Copy        readable RAM copy
 regUserWriteBit      ReadWrite        mapped writable
                      Read             mapped readonly
                      ReadWrite|Copy   writeable RAM copy 
                      Read|Copy        readable RAM copy

The "Read|Copy" rows are not required for this release.

If mapViewMinimumCopy is set the result is boundedly undefined.

For reference mapViewAccessTYP is mapViewReadWrite, mapViewRead, mapViewMinimumCopy, mapViewCopy

The mapViewOfKernelFile also references downloadingPermitted and executeOutOfRAM. Current philosophy is that effect of downloadingPermitted and executeOutOfRAM are the responsibility of the file system to define. Currently only the legacy (VAS based) file system will address them.

Platform resources never have frozen pages, so the definition of "thawing" for a platform resource attachment has to change to "always make a RAM copy for all pages in the range".

readFromPlatformResource

Modeled as much as possible after readFromKernelFile (also refer to readPlatformResource32), with the following changes:

Reads from an unattached platform resource, so resource name replaces handle/filename
Only applies to memoryAccess resources

It would have been nice to be able to use readPlatformResource32, but the whole idea here is to not have resource handles.

The other think considered was to provide some means for a page of virtual address to be allocated as part of the file system to use as a temporary location where (a or several) page(s) of a platform resource could be mapped. This is required for basic image loading (determining ELF header info), and also for "copy to RAM" (creating data sections). The problem is that in the presence of exceptions that could use the file APIs, it wouldn't be acceptable to have just one page per file system, or one page per thread, each API call would need to allocate and return a page (ala portals), that that is very messy.

Boot Image Tooling

Use Case

Desert_Eagle_Program may require on the order of hundred(s) of configurations. Use case proposed:

Selection archive to choose one of N different configurations.
- Each element would be a composite archive of references
The actual KFS/hypstart images would be placed in a different archive.

Current Design

Current types boot image files:

kfs See #KFS_Format contains MFS, and later perhaps LFS)
hypstart
selection archive
composite archive
reference
compressed

All but compressed needed for Nov 15 release.

There will be at least 3 tools involved:

hypstart
MFS tool name name tbd
other

Need both creator and printer tools. Printer tool is not required for Nov 15 release.

What does the specification language look like?

commands that generate the artifacts
a spec language, e.g., xml

For now use command line tools. Pick good file extensions so we can use make(1) as our spec language.

The only integrity algorithm needed at this time is CRC.

Chuck can start on archive and reference tools. Work can procede in hypstart mainline.

Registry Content

Incomplete.

list of platform resources that will be auto mounted as KFSes at process startup.
The quota of mount points
- TBD whether integ tool needs to account for the resulting primary thread stack usage.

Integration/Specification Notes

2025-11-04 meeting notes

Aaron Larson, Lisa Jett, Gary Kindorf, Kenneth Tope, Mathew Carroll

MFS needs to contain files from various components/projects.

Executable projects provide data to MFS (e.g., hello-world.exe), but need to use MFS artifacts also to gain access to the MFS at runtime (e.g., the .fp.xml).

Each process that needs to use an MFS:

platform resource quota
platform resource ownership
mount quota
search path
"automountPath" (filename where MFS is mounted) attribute of ownedFileSystem element within processInstance.

There is a tension between:

Does the component know which MFS (or MFSes) it is integrated into
Does the system configuration specify that info, and if so, how does the process get updated to account for the quotas of all the MFS(es) that contain the component artifacts.

System concerns:

MFS platform resources must be isomorphic for all registries used by a "Deos system"
1. Some aspects of MFS need to be in all registries: platform resource .pia files.
2. Other aspects registry specific, quotas, ownership, mount info, etc.
Different processes need different info in different registries.
1. MFSes need to be updatable by FTP (development/field load issue only?)
2. Processes integrated into registries need more.
How are search paths managed:
1. Must be process specific
2. Would be nice if MFSes could automatically appear in process search path.

Ownership of MFS

How does executable provide .exe files and yet still specify that it needs access to the MFS.

kfs.xml

Describes the component and files to be included in the MFS.
Does not enumerate which processes have access to the MFS.
1. Current recollection is that including such information in .kfs.xml was problematic.
2. Pretend we are going to include list of owners for the MFS.

Pretend we have a "KFS resource" specification that:

Defines platform resource attributes
List of processes that will mount the file system
List of processes that will update the file system

Ideas:

MFS is defined in a meta data project.
1. .kfs.xml
2. generate .fp, IT related files

registry qualifier on kernelFile is not flagged as an error.

Virtual Filesystem Interface

Define an interface for a Deos filesystem. Initially it would support read only file access and image loading, but would be designed to be extensible for writable filesystems as well.

The filesystems would be "mountable". Initially mounting a filesystem would overlay the root filesystem, i.e., the files in the mounted filesystem would appear to be in the same directory as all other filesystems. Likely we would add a directory based mount in the future.

Implementations Of The VFS

Kernel Filesystem

A filesystem that maintains the interface of the Deos native kernel filesystem, but making it possible to have multiple instances of the filesystem.

Read Only RAM Based

This would support the "special binary" use case. The entire filesystem would be writable, but individual files would be read only. This would be like writing to a raw disk drive partition. This view permits the filesystem implementation to be very simple.

Notes in raw format from the geekfest wiki

kernel dependencies on the kernel filesystem (currently)

   basic operations:
     file name enumeration and lookup
     checkKernelFileIntegrity()
     mapViewOfKernelFile()
     loadLibraryDeos()
     readFromKernelFile()

   each process has a local list of FileSystem objects on the main processes stack, along with the
   head of the list, the head could be updated.  Kernel just has to return the address of the head
   pointer.

   none of our tools has a sense of directory structure:
     no search path
     no library path
     no current working directory


Ideas

For now All of these data structures and functions are kernel private.
If they were made public, extra headers for version and size protocols
would be required.

A file system is an abstract data type defined entirely by a set of
operations.  The first parameter to each operation is a pointer to an
instance of its file system.

struct KernelFileSystemOperations
{

   collection of function pointers, structure member names would be
   sans the "Kernel", all returning kernelFileStatus.  The operations
   are:
     mapViewOfKernelFile
     firstKernelFile
     nextKernelFile
     checkKernelFileIntegrity (might be optional)
     kernelFileSystemInfo     (might be optional)
     readFromKernelFile
}

// A mount table is a vector of MountTableEntry_t.  If unmount is
// defined, or user mount entries are permitted, then this structure
// would get more complicated.
struct MountTable
{
   _maxNumEntries; // Declared length of _entries;
   _numAllocatedEntries; // Num _entries mounted.
   MountTableEntry_t _entries[]
}

struct MountTableEntry_t   // linked list node
{
   headers; // Kernel defined.  Any TBD info needed to manage mount tables, e.g., linked list nodes, etc.
   KernelFileSystemOperations ops; 
   void *fileSystem;   // ops specific data, typically a pointer to the mounted file system 
} mountTable;

// Open finds a file in a mounted file system
someType open(filename)
{
   foreach m in mountTable
   {
      {status, handle} = m->ops.firstFile(m->fileSystem, filename);
      if status == success return success, m, handle
   }
   return failure
}

someType mapViewOfKernelFile(filename, ...)
{
   m is a MountTableEntry_t
   (m, handle) = open(filename)
   if (failed) return filenotfound;
   status = m->ops.mapViewOfFile(m->fileSystem, handle, ...);
   // No close at this time.  m->ops.close(m->fileSystem, handle)
   return status;
}

Registry in KFSn

Goal separate the registry from the hyperstart image (kfs0)

proposal:

BIO defines registry KFS physical address.
- Requires boot to support version 1 of the BIO.
  - Certified boots must already do this.
  - Rebuild with kernel 9.2.0 should be sufficient.
- Set at hyperstart time but can be changed by boot before starting the kernel.
- Will it be possible to set via setKernelAttributesEX?
  - Perhaps use the hyp boot index most sig 16 bits?
mounts the registry KFS
Kernel loads registry to get the other KFSes.

Observations:

Enables the PAL to be out side of kfs0
kfs0 can become kernel plus hypstart configuration data. Stated another way the only file that has to be in the hyperstart image is the kernel.
Seems like we should be able to do something with this but not sure what.

Estimate:

6 weeks

BOE:

Adder on top of multiple KFSes

Kernel:

coldstart()
setKernelAttributes[Ex]()

Hypstart:

remove/change check for registry.

Boot:

mode changes when the registry's kfs changes

Deos Modular Filesystem