View source for Deos Modular Filesystem

From DDCIDeos
You do not have permission to edit this page, for the following reason:
The action you have requested is limited to users in the group: Users.
You can view and copy the source of this page.
= 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.

<ol>
  <li>Create hello world example</li>
  <li>Add dependency to ansi</li>
  <li>Replace hello-world.cpp with [[Media:Multiple-file-system-hello-world.cpp.txt|Save As this link to hello-world.cpp in your workspace]]</li>
  <li>Upate hello-world.pd.xml:
     <pre>mountQuota = "2"
         Within the process instance:
         Update fileSystemSearchPath to: fileSystemSearchPath = "/hello:/"
         Add:
         <ownedFileSystems>
            <ownedFileSystem
                 resourceName = "SCATHitmap"
               >
               <automount
                    mountPath = "/hello"
               ></automount>
            </ownedFileSystem>
         </ownedFileSystems>
</pre></li>
  <li>Upate platreg.pi.xml: memoryMappedResource SCATHitmap, <pre>allowMultipleOwners = "yes"</pre></li>
  <li>Update target load but DO NOT put hello-world.exe</li>
  <li>Create a MFS image:
    <pre>
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
</pre>
ppc:
<pre>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
</pre>
For x86, the mkkfs.py command must be (the image is too large to include t1.txt):
<pre>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</pre>
</li>
  <li>Put the image on the target: <pre>putapp kfs1.arm.mfs /proc/res/SCATHitmap</pre>
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:<pre>
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</pre>
x86:
<pre>putapp kfs1.x86.mfs /proc/vm/0x001f8000</pre>
</li>
</ol>


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]] <br>
'''Task name:''' (F13) KFS Individual part number <br>
'''Planned Completion:''' November 15, 2019 (Stable) Single digit priorities only.<br>

<!-- status is: Hold, Pending, {{Work}}, {{Done}} -->
{| class="wikitable sortable mwcalc mw-collapsible" border="1"
|- align="center" style="background: silver"
! Task                                          !! Priority !! Assignee !! Status !! data-sort-type="number"|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]]:

<blockquote>
    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.
</blockquote>

== 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:

<pre>
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
</pre>

= 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.
## 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".
## The entries in the directory must be lexicographically ordered by file name.
## 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
{{SERVER}}/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 ====

<pre>
// 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.
</pre>

=== 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"
## Some aspects of MFS need to be in all registries: platform resource .pia files.
## Other aspects registry specific, quotas, ownership, mount info, etc.
# Different processes need different info in different registries.
## MFSes need to be updatable by FTP (development/field load issue only?)
## Processes integrated into registries need more.
# How are search paths managed:
## Must be process specific
## 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.
## Current recollection is that including such information in .kfs.xml was problematic.
## 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.
## .kfs.xml
## 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.

<hr><pre>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;
}
</pre>

= 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

[[Category:Projects]]
<!-- Uncomment one of these
[[Category:Active_Projects]]
[[Category:Completed_Projects]]
[[Category:On_Hold_Projects]]
-->
[[Category:Active_Projects]]
Page included on this page:
Template:Test (view source)
Return to Deos Modular Filesystem.
Retrieved from "https://ddci.zapto.org/ddciWiki/Deos_Modular_Filesystem"
View source for Deos Modular Filesystem

Navigation menu

Page actions

Page actions

Personal tools

Navigation

Search

DDCI Tools & Resources

DDC-I private

Shared IP

Other

Tools
