1.1 --- a/docs/tools/depgraph Sat Aug 28 00:26:18 2021 +0200
1.2 +++ b/docs/tools/depgraph Sat Aug 28 00:28:46 2021 +0200
1.3 @@ -24,7 +24,7 @@
1.4
1.5 filter_libraries()
1.6 {
1.7 - grep -v '<l4\|<systypes\|<std\|<list>\|<map>\|<mutex>\|<condition_variable>'
1.8 + grep -v '<l4\|<systypes\|<std\|<list>\|<map>\|<mutex>\|<condition_variable>\|<string>\|<set>\|<vector>'
1.9 }
1.10
1.11 # Select basenames in search result filenames.
1.12 @@ -86,7 +86,7 @@
1.13 | colour_sources \
1.14 | select_basenames \
1.15 | sed 's/\.cc//' \
1.16 -| sed 's/$/;/' \
1.17 +| sed 's/^/ /;s/$/;/' \
1.18 >> "$DOTFILE"
1.19
1.20 # Generate header file relationships.
2.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
2.2 +++ b/docs/wiki/ClientLibrary Sat Aug 28 00:28:46 2021 +0200
2.3 @@ -0,0 +1,146 @@
2.4 += Client Library =
2.5 +
2.6 +The filesystem client library offers abstractions and a number of layers of
2.7 +functionality to support interaction with [[Components|components]] and the
2.8 +provision of higher-level mechanisms and abstractions for file access.
2.9 +
2.10 +<<TableOfContents(2,3)>>
2.11 +
2.12 +== File Data Structures ==
2.13 +
2.14 +Since files are accessed using file references, the `file_t` data structure is
2.15 +used to wrap such references and other relevant state. Thus, such structures
2.16 +can be broadly regarded as similar to the traditional `FILE` data structure.
2.17 +
2.18 +The fields of the `file_t` data structure are as follows:
2.19 +
2.20 +|| '''Field''' || '''Description''' ||
2.21 +|| `memory` || The memory address of the exposed file region ||
2.22 +|| `start_pos` || The start position of the region in the file ||
2.23 +|| `end_pos` || The end position of the region in the file ||
2.24 +|| `data_end` || The amount or extent of populated data in the region ||
2.25 +|| `data_current` || The offset used to track client position in the region ||
2.26 +|| `size` || The total size of the file ||
2.27 +|| `object_flags` || Flags indicating support for certain file features ||
2.28 +|| `can_block` || Notification flags for blocking access to the file ||
2.29 +|| `notifications`|| Notification flags set for the file ||
2.30 +
2.31 +== Client Programming Interface ==
2.32 +
2.33 +The client programming interface provides functions somewhat resembling the
2.34 +traditional C library and low-level Unix interfaces for file access, and these
2.35 +functions are intended to support such traditional interfaces.
2.36 +
2.37 +=== Files ===
2.38 +
2.39 +Files are opened and closed using the following functions:
2.40 +
2.41 +{{{
2.42 +file_t *client_open(const char *name, flags_t flags);
2.43 +}}}
2.44 +
2.45 +Each file endpoint may be closed using `client_close`.
2.46 +
2.47 +=== Pipes ===
2.48 +
2.49 +Pipes are opened using a special function:
2.50 +
2.51 +{{{
2.52 +long client_pipe(file_t **reader, file_t **writer, flags_t flags);
2.53 +}}}
2.54 +
2.55 +Each pipe endpoint may be closed using `client_close`.
2.56 +
2.57 +=== Closing Files and Pipes ===
2.58 +
2.59 +Closing files and pipes involves a common operation:
2.60 +
2.61 +{{{
2.62 +void client_close(file_t *file);
2.63 +}}}
2.64 +
2.65 +When client programs terminate, the freeing of their object capabilities
2.66 +should cause the closure of files and pipes, but programs may choose to close
2.67 +such resources explicitly.
2.68 +
2.69 +=== Reading and Writing ===
2.70 +
2.71 +Reading and writing files and pipes involves functions resembling the
2.72 +traditional low-level `read` and `write` functions:
2.73 +
2.74 +{{{
2.75 +offset_t client_read(file_t *file, void *buf, offset_t count);
2.76 +offset_t client_write(file_t *file, const void *buf, offset_t count);
2.77 +}}}
2.78 +
2.79 +=== Navigation in Files ===
2.80 +
2.81 +Support for navigation in files is provided using functions resembling the
2.82 +traditional higher-level `fseek` and `ftell` functions:
2.83 +
2.84 +{{{
2.85 +offset_t client_seek(file_t *file, offset_t offset, int whence);
2.86 +long client_tell(file_t *file);
2.87 +}}}
2.88 +
2.89 +=== Accessing Exposed Memory Regions ===
2.90 +
2.91 +Although the client library (and the provision of files) employs mapped
2.92 +memory, a function can be used to explicitly reference memory for file access:
2.93 +
2.94 +{{{
2.95 +void *client_mmap(file_t *file, offset_t position, offset_t length);
2.96 +}}}
2.97 +
2.98 +Pipes support a different mechanism for navigation involving the following
2.99 +functions:
2.100 +
2.101 +{{{
2.102 +long client_current_region(file_t *file);
2.103 +long client_next_region(file_t *file);
2.104 +}}}
2.105 +
2.106 +Such navigation functions for files and pipes do not need to be used where the
2.107 +higher-level reading, writing and seeking functions are in use.
2.108 +
2.109 +=== Flushing and Synchronisation ===
2.110 +
2.111 +For synchronisation purposes, either with the filesystem itself or with other
2.112 +users of the filesystem, a function resembling the traditional `fflush`
2.113 +function is provided:
2.114 +
2.115 +{{{
2.116 +long client_flush(file_t *file);
2.117 +}}}
2.118 +
2.119 +This updates the file data structure with new details of the file size, also
2.120 +updating any altered details of the extent of the data in the currently
2.121 +accessed region of the file.
2.122 +
2.123 +=== Notifications ===
2.124 +
2.125 +Since files and pipes may be accessed by multiple clients, necessarily for any
2.126 +sensible use of the latter, notifications can be configured to communicate a
2.127 +change in state to other users of these resources when they are accessed.
2.128 +
2.129 +Notification types are specified using values encoding a number of flags, and
2.130 +the following flags are available for this purpose:
2.131 +
2.132 +|| '''Flag''' || '''Notification Type''' ||
2.133 +|| `NOTIFY_CONTENT_AVAILABLE` || Content available to read ||
2.134 +|| `NOTIFY_PEER_CLOSED` || Other party has closed their endpoint ||
2.135 +|| `NOTIFY_SPACE_AVAILABLE` || Space available for writing ||
2.136 +
2.137 +=== Blocking Operations ===
2.138 +
2.139 +Reading and writing operations can be configured to block if data cannot be
2.140 +read or written respectively. The following function is provided for this
2.141 +purpose:
2.142 +
2.143 +{{{
2.144 +long client_set_blocking(file_t *file, notify_flags_t flags);
2.145 +}}}
2.146 +
2.147 +For pipes, blocking behaviour is the default and must be disabled explicitly,
2.148 +either by opening using the `O_NONBLOCK` flag or by calling
2.149 +`client_set_blocking` with no flags set.
3.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
3.2 +++ b/docs/wiki/Components Sat Aug 28 00:28:46 2021 +0200
3.3 @@ -0,0 +1,227 @@
3.4 += Components =
3.5 +
3.6 +Access to files is provided by a number of programs acting as components. For
3.7 +convenience, the component-level operations are wrapped up in a
3.8 +[[ClientLibrary|client library]] that aims to provide simpler, more familiar
3.9 +mechanisms for opening, reading, writing, and closing files, together with
3.10 +various other operations.
3.11 +
3.12 +<<TableOfContents(2,3)>>
3.13 +
3.14 +Components are accessed via interfaces defined using the interface description
3.15 +language supported by the ``idl4re`` tool. Interface operations in this
3.16 +document are described using excerpts from the appropriate interface
3.17 +descriptions.
3.18 +
3.19 +######## A graph showing the interactions between components
3.20 +
3.21 +{{{#!graphviz
3.22 +#format svg
3.23 +#transform notugly
3.24 +digraph components {
3.25 + node [fontsize="12.0",fontname="sans-serif",shape=box];
3.26 + edge [fontsize="12.0",fontname="sans-serif"];
3.27 + rankdir=LR;
3.28 +
3.29 + subgraph {
3.30 + node [label="Client",style=solid,color="#000000",fontcolor="#000000"];
3.31 + rank=min;
3.32 +
3.33 + Client1; Client3; Client5;
3.34 +
3.35 + subgraph {
3.36 + node [label="Client",color="#999999",fontcolor="#999999"];
3.37 + Client2; Client4; Client6;
3.38 + }
3.39 + }
3.40 +
3.41 + subgraph {
3.42 + rank=same;
3.43 + Filesystem;
3.44 +
3.45 + subgraph {
3.46 + node [label="Opener\n(user)"];
3.47 + Opener1; Opener2;
3.48 + }
3.49 +
3.50 + subgraph {
3.51 + node [label="OpenerContext"];
3.52 + OpenerContext1; OpenerContext2;
3.53 + }
3.54 +
3.55 + MappedFile;
3.56 + }
3.57 +
3.58 + Client1 -> Client2 -> Client3 -> Client4 -> Client5 -> Client6 [arrowhead=none,style=invisible];
3.59 + Opener1 -> Opener2 [arrowhead=none,style=invisible];
3.60 + OpenerContext1 -> OpenerContext2 [arrowhead=none,style=invisible];
3.61 +
3.62 + Client1 -> Filesystem [label="open_for_user(user)"];
3.63 + Filesystem -> Opener1;
3.64 + Opener1 -> Client2 [style=dashed];
3.65 +
3.66 + Client3 -> Opener2 [label="context()"];
3.67 + Opener2 -> OpenerContext1;
3.68 + OpenerContext1 -> Client4 [style=dashed];
3.69 +
3.70 + Client5 -> OpenerContext2 [label="open(flags, ...)"];
3.71 + OpenerContext2 -> MappedFile;
3.72 + MappedFile -> Client6 [style=dashed];
3.73 +}
3.74 +}}}
3.75 +
3.76 +########
3.77 +
3.78 +== Filesystems ==
3.79 +
3.80 +Filesystems implement the `Filesystem` interface which provides the
3.81 +`open_for_user` operation:
3.82 +
3.83 +{{{
3.84 +open_for_user(in user_t user, out cap opener)
3.85 +}}}
3.86 +
3.87 +The operation yields a file opener appropriate for the given [[Users|user]]
3.88 +credentials.
3.89 +
3.90 +== File Openers ==
3.91 +
3.92 +File openers implement the `Opener` interface which provides the `context`
3.93 +operation:
3.94 +
3.95 +{{{
3.96 +context(out cap context)
3.97 +}}}
3.98 +
3.99 +Each client program, task or thread obtains its own context because it will
3.100 +need its own dedicated channel for communication with the filesystem.
3.101 +
3.102 +== Opener Contexts ==
3.103 +
3.104 +An opener context acts as a dataspace, meaning that it can be attached to a
3.105 +task using a region manager and provide a buffer via a region of mapped memory
3.106 +that the task can write to. In the case of a context, the task will write a
3.107 +filesystem path indicating the file to be opened.
3.108 +
3.109 +Each context allows a client program to request access to individual files via
3.110 +operations provided by the `OpenerContext` interface, of which the most
3.111 +pertinent is the `open` operation:
3.112 +
3.113 +{{{
3.114 +open(in flags_t flags, out offset_t size, out cap file,
3.115 + out object_flags_t object_flags)
3.116 +}}}
3.117 +
3.118 +Using the path information written to the context's memory region, the `open`
3.119 +operation will obtain a reference to a file-like object whose characteristics
3.120 +are described by the accompanying `object_flags`, these helping the client to
3.121 +distinguish between files that support arbitrary memory mapping operations and
3.122 +pipes that mandate sequential region-by-region access.
3.123 +
3.124 +Alongside regular files, directories may also be opened. Reading from them
3.125 +yields a listing of directory entries.
3.126 +
3.127 +== Files ==
3.128 +
3.129 +Files themselves act as dataspaces, meaning that they can be attached to a
3.130 +task using a region manager and provide their content via a region of mapped
3.131 +memory. Files implement the `MappedFile` interface.
3.132 +
3.133 +Control over the region of the file provided via mapped memory occurs
3.134 +using the `mmap` operation:
3.135 +
3.136 +{{{
3.137 +mmap(in offset_t position, in offset_t length,
3.138 + out offset_t start_pos, out offset_t end_pos,
3.139 + out offset_t size)
3.140 +}}}
3.141 +
3.142 +Files also implement the more general `File` interface that provides the
3.143 +`resize` operation:
3.144 +
3.145 +{{{
3.146 +resize(inout offset_t size)
3.147 +}}}
3.148 +
3.149 +This allows the portion of the memory region dedicated to the file's contents
3.150 +to be extended.
3.151 +
3.152 +== Directories ==
3.153 +
3.154 +Directories are also meant to be accessed like files, meaning that it should
3.155 +be possible to attach them to a task using a region manager and access the
3.156 +provided content, this being a listing of directory entries, via the mapped
3.157 +region.
3.158 +
3.159 +However, unlike files which may support arbitrary mapping of their contents,
3.160 +the provided content may be supplied by a pipe endpoint, thereby not
3.161 +supporting precisely the same navigation mechanisms as those supported by
3.162 +files.
3.163 +
3.164 +'''Note''' that directories may well be redefined to support multiple
3.165 +operations, one of which supporting the file-like access described above.
3.166 +
3.167 +== Pipe Openers ==
3.168 +
3.169 +Distinct from filesystems but potentially used by them, pipe openers provide a
3.170 +means of obtaining pipes, which are channels that support unidirectional
3.171 +communication via shared memory.
3.172 +
3.173 +Pipe openers implement the `PipeOpener` interface and support the following
3.174 +operation:
3.175 +
3.176 +{{{
3.177 +pipe(in offset_t size, out cap reader, out cap writer)
3.178 +}}}
3.179 +
3.180 +The size is indicated to request pipe regions long enough for the needs of the
3.181 +communicating parties, with both reader and writer endpoint capabilities being
3.182 +returned. Such capabilities may be propagated to the eventual parties, these
3.183 +typically being separate tasks.
3.184 +
3.185 +== Pipes ==
3.186 +
3.187 +Although not generally obtained from filesystems, pipes may be involved in
3.188 +providing content from some filesystem objects such as directories. However,
3.189 +they are also obtained directly from an appropriate pipe server providing pipe
3.190 +opening facilities.
3.191 +
3.192 +Pipes expose single regions of shared memory to their endpoints, with the
3.193 +writing endpoint populating one region while the reading endpoint accesses the
3.194 +other. The reading endpoint may advance to the region being written, and this
3.195 +will free up a new region for the writer when it has filled its region. When
3.196 +the writer itself advances, it permits the reader to consume all data in the
3.197 +fully populated region. Naturally, the reader may not advance ahead of the
3.198 +writer.
3.199 +
3.200 +Pipes implement the `Pipe` interface and a number of operations to support
3.201 +this interaction mechanism.
3.202 +
3.203 +The details of an endpoint's current region can be queried using the following
3.204 +operation:
3.205 +
3.206 +{{{
3.207 +current_region(out offset_t populated_size, out offset_t size)
3.208 +}}}
3.209 +
3.210 +This provides details of the populated size (or amount of written data) in a
3.211 +region along with the size of the region.
3.212 +
3.213 +Navigation to the next available region of the pipe is performed using the
3.214 +following operation:
3.215 +
3.216 +{{{
3.217 +next_region(inout offset_t populated_size, out offset_t size)
3.218 +}}}
3.219 +
3.220 +Here, the populated size may be specified by the writer so that the reader may
3.221 +query the current region's properties using the appropriate operation.
3.222 +
3.223 +The status of the pipe can be queried using the `closed` operation:
3.224 +
3.225 +{{{
3.226 +closed(out int closed)
3.227 +}}}
3.228 +
3.229 +This indicates through a boolean-equivalent parameter whether one or both
3.230 +endpoints have been closed.
4.1 --- a/docs/wiki/Files Sat Aug 28 00:26:18 2021 +0200
4.2 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000
4.3 @@ -1,237 +0,0 @@
4.4 -= Files =
4.5 -
4.6 -Access to files is provided by a number of programs acting as components. For
4.7 -convenience, the component-level operations are wrapped up in a client library
4.8 -that aims to provide simpler, more familiar mechanisms for opening, reading,
4.9 -writing, and closing files, together with various other operations.
4.10 -
4.11 -<<TableOfContents(2,3)>>
4.12 -
4.13 -== Components ==
4.14 -
4.15 -At the lowest level in L4Re, files are accessed via a suite of components.
4.16 -These components are principally of interest to library developers since they
4.17 -only provide a limited level of abstraction.
4.18 -
4.19 -=== Filesystems ===
4.20 -
4.21 -Filesystems implement the `Filesystem` interface which provides the
4.22 -`open_for_user` operation:
4.23 -
4.24 -{{{
4.25 -open_for_user(in user_t user, out cap opener)
4.26 -}}}
4.27 -
4.28 -The operation yields a file opener appropriate for the given user credentials.
4.29 -
4.30 -=== File Openers ===
4.31 -
4.32 -File openers implement the `Opener` interface which provides the `context`
4.33 -operation:
4.34 -
4.35 -{{{
4.36 -context(out cap context)
4.37 -}}}
4.38 -
4.39 -Each client program, task or thread obtains its own context because it will
4.40 -need its own dedicated channel for communication with the filesystem.
4.41 -
4.42 -=== Contexts ===
4.43 -
4.44 -A context acts as a dataspace, meaning that it can be attached to a task using
4.45 -a region manager and provide a buffer via a region of mapped memory that the
4.46 -task can write to. In the case of a context, the task will write a filesystem
4.47 -path indicating the file to be opened.
4.48 -
4.49 -Each context allows a client program to request access to individual files via
4.50 -operations provided by the `OpenerContext` interface, of which the most
4.51 -pertinent is the `open` operation:
4.52 -
4.53 -{{{
4.54 -open(in flags_t flags, out offset_t size, out cap file,
4.55 - out object_flags_t object_flags)
4.56 -}}}
4.57 -
4.58 -Using the path information written to the context's memory region, the `open`
4.59 -operation will obtain a reference to a file-like object whose characteristics
4.60 -are described by the accompanying `object_flags`, these helping the client to
4.61 -distinguish between files that support arbitrary memory mapping operations and
4.62 -pipes that mandate sequential region-by-region access.
4.63 -
4.64 -Alongside regular files, directories may also be opened. Reading from them
4.65 -yields a listing of directory entries.
4.66 -
4.67 -=== Files ===
4.68 -
4.69 -Files themselves act as dataspaces, meaning that they can be attached to a
4.70 -task using a region manager and provide their content via a region of mapped
4.71 -memory. Files implement the `MappedFile` interface.
4.72 -
4.73 -Control over the region of the file provided via mapped memory occurs
4.74 -using the `mmap` operation:
4.75 -
4.76 -{{{
4.77 -mmap(in offset_t position, in offset_t length,
4.78 - out offset_t start_pos, out offset_t end_pos,
4.79 - out offset_t size)
4.80 -}}}
4.81 -
4.82 -Files also implement the more general `File` interface that provides the
4.83 -`resize` operation:
4.84 -
4.85 -{{{
4.86 -resize(inout offset_t size)
4.87 -}}}
4.88 -
4.89 -This allows the portion of the memory region dedicated to the file's contents
4.90 -to be extended.
4.91 -
4.92 -=== Directories ===
4.93 -
4.94 -Directories are also meant to be accessed like files, meaning that it should
4.95 -be possible to attach them to a task using a region manager and access the
4.96 -provided content, this being a listing of directory entries, via the mapped
4.97 -region.
4.98 -
4.99 -However, unlike files which may support arbitrary mapping of their contents,
4.100 -the provided content may be supplied by a pipe endpoint, thereby not
4.101 -supporting precisely the same navigation mechanisms as those supported by
4.102 -files.
4.103 -
4.104 -=== Pipe Openers ===
4.105 -
4.106 -Distinct from filesystems but potentially used by them, pipe openers provide a
4.107 -means of obtaining pipes, which are channels that support unidirectional
4.108 -communication via shared memory.
4.109 -
4.110 -Pipe openers implement the `PipeOpener` interface and support the following
4.111 -operation:
4.112 -
4.113 -{{{
4.114 -pipe(in offset_t size, out cap reader, out cap writer)
4.115 -}}}
4.116 -
4.117 -The size is indicated to request pipe regions long enough for the needs of the
4.118 -communicating parties, with both reader and writer endpoint capabilities being
4.119 -returned. Such capabilities may be propagated to the eventual parties, these
4.120 -typically being separate tasks.
4.121 -
4.122 -=== Pipes ===
4.123 -
4.124 -Although not generally obtained from filesystems, pipes may be involved in
4.125 -providing content from some filesystem objects such as directories. However,
4.126 -they are also obtained directly from an appropriate pipe server providing pipe
4.127 -opening facilities.
4.128 -
4.129 -Pipes expose single regions of shared memory to their endpoints, with the
4.130 -writing endpoint populating one region while the reading endpoint accesses the
4.131 -other. The reading endpoint may advance to the region being written, and this
4.132 -will free up a new region for the writer when it has filled its region. When
4.133 -the writer itself advances, it permits the reader to consume all data in the
4.134 -fully populated region. Naturally, the reader may not advance ahead of the
4.135 -writer.
4.136 -
4.137 -Pipes implement the `Pipe` interface and a number of operations to support
4.138 -this interaction mechanism.
4.139 -
4.140 -The details of an endpoint's current region can be queried using the following
4.141 -operation:
4.142 -
4.143 -{{{
4.144 -current_region(out offset_t populated_size, out offset_t size)
4.145 -}}}
4.146 -
4.147 -This provides details of the populated size (or amount of written data) in a
4.148 -region along with the size of the region.
4.149 -
4.150 -Navigation to the next available region of the pipe is performed using the
4.151 -following operation:
4.152 -
4.153 -{{{
4.154 -next_region(inout offset_t populated_size, out offset_t size)
4.155 -}}}
4.156 -
4.157 -Here, the populated size may be specified by the writer so that the reader may
4.158 -query the current region's properties using the appropriate operation.
4.159 -
4.160 -The status of the pipe can be queried using the `closed` operation:
4.161 -
4.162 -{{{
4.163 -closed(out int closed)
4.164 -}}}
4.165 -
4.166 -This indicates through a boolean-equivalent parameter whether one or both
4.167 -endpoints have been closed.
4.168 -
4.169 -== Libraries ==
4.170 -
4.171 -The filesystem client library offers abstractions and a number of layers of
4.172 -functionality to support interaction with components and the provision of
4.173 -higher-level mechanisms and abstractions for file access.
4.174 -
4.175 -=== Client Library ===
4.176 -
4.177 -The client library provides functions somewhat resembling the traditional C
4.178 -library and low-level Unix interfaces for file access, and these functions are
4.179 -intended to support such traditional interfaces.
4.180 -
4.181 -Since files are accessed using file references, the `file_t` data structure is
4.182 -used to wrap such references and other relevant state. Thus, such structures
4.183 -can be broadly regarded as similar to the traditional `FILE` data structure.
4.184 -
4.185 -Files are opened and closed using the following functions:
4.186 -
4.187 -{{{
4.188 -file_t *client_open(const char *name, flags_t flags);
4.189 -void client_close(file_t *file);
4.190 -}}}
4.191 -
4.192 -Pipes are opened using a special function:
4.193 -
4.194 -{{{
4.195 -long client_pipe(file_t **reader, file_t **writer, flags_t flags);
4.196 -}}}
4.197 -
4.198 -Each pipe endpoint may be closed using `client_close`.
4.199 -
4.200 -Reading and writing files and pipes involves functions resembling the
4.201 -traditional low-level `read` and `write` functions:
4.202 -
4.203 -{{{
4.204 -offset_t client_read(file_t *file, void *buf, offset_t count);
4.205 -offset_t client_write(file_t *file, const void *buf, offset_t count);
4.206 -}}}
4.207 -
4.208 -Support for navigation in files is provided using functions resembling the
4.209 -traditional higher-level `fseek` and `ftell` functions:
4.210 -
4.211 -{{{
4.212 -offset_t client_seek(file_t *file, offset_t offset, int whence);
4.213 -long client_tell(file_t *file);
4.214 -}}}
4.215 -
4.216 -Although the client library (and the provision of files) employs mapped
4.217 -memory, a function can be used to explicitly reference memory for file access:
4.218 -
4.219 -{{{
4.220 -void *client_mmap(file_t *file, offset_t position, offset_t length);
4.221 -}}}
4.222 -
4.223 -Pipes support a different mechanism for navigation involving the following
4.224 -functions:
4.225 -
4.226 -{{{
4.227 -long client_current_region(file_t *file);
4.228 -long client_next_region(file_t *file);
4.229 -}}}
4.230 -
4.231 -Such navigation functions for files and pipes do not need to be used where the
4.232 -higher-level reading, writing and seeking functions are in use.
4.233 -
4.234 -For synchronisation purposes, either with the filesystem itself or with other
4.235 -users of the filesystem, a function resembling the traditional `fflush`
4.236 -function is provided:
4.237 -
4.238 -{{{
4.239 -long client_flush(file_t *file);
4.240 -}}}
5.1 --- a/docs/wiki/Filesystems Sat Aug 28 00:26:18 2021 +0200
5.2 +++ b/docs/wiki/Filesystems Sat Aug 28 00:28:46 2021 +0200
5.3 @@ -5,4 +5,6 @@
5.4
5.5 == Topics ==
5.6
5.7 - * [[Files]]
5.8 + * [[Components]]
5.9 + * [[ClientLibrary|Client Library]]
5.10 + * [[Users]]