Changes between Version 18 and Version 19 of FSDesign

Timestamp:

2009-11-17T15:28:52Z (15 years ago)

Author:

Jakub Jermář

Comment:

—

FSDesign

@@ -46 +46 @@
 reference some file and, as we will see later, the frontend always converts this reference to
 an internal representation called VFS node.
+
+Each request understood by the frontend has a symbolic name, which starts with the VFS_IN prefix.
 
 ==== Paths as Arguments ====
@@ -133 +135 @@
 As soon as the VFS server knows the VFS node associated with the request, it either asks one of the endpoint file system servers to carry out the operation for it or, when it has enough information, it completes the operation itself. For example, VFS handles the VFS_IN_SEEK request, which corresponds to the POSIX call ''lseek()'', entirely on its own, because it just manipulates the current position pointer within the respective ''vfs_file_t'' structure. In the worst case, when seeking to the end of the file, VFS needs to know the size of the file, but this is not a problem, because the server maintains the current file size in each VFS node.
 
-We refer to the part which communicates with the endpoint file system servers as to VFS backend. VFS backend knows the handle of the endpoint file system (and also of the underlying device) from the VFS node, so it can use it to obtain an IPC phone and communicate with it. 
+We refer to the part which communicates with the endpoint file system servers as to VFS backend. VFS backend knows the handle of the endpoint file system (and also of the underlying device) from the VFS node, so it can use it to obtain an IPC phone and communicate with it. The set of calls that VFS can make to an endpoint file system server defines the VFS output protocol because all potential endpoint file system servers need to understand it and implement it in some way.
+
+The symbolic names of requests in the VFS output protocol are prefixed with VFS_OUT.