From 78e51a8c6678b6e3dff3d619aa786669f531f4bc Mon Sep 17 00:00:00 2001 From: rsc Date: Fri, 14 Jan 2005 03:45:44 +0000 Subject: checkpoint --- man/man4/9pserve.html | 79 +++++++++++++++ man/man4/acme.html | 268 ++++++++++++++++++++++++++++++++++++++++++++++++++ man/man4/import.html | 107 ++++++++++++++++++++ man/man4/index.html | 49 +++++++++ man/man4/intro.html | 92 +++++++++++++++++ man/man4/plumber.html | 122 +++++++++++++++++++++++ man/man4/ramfs.html | 81 +++++++++++++++ 7 files changed, 798 insertions(+) create mode 100644 man/man4/9pserve.html create mode 100644 man/man4/acme.html create mode 100644 man/man4/import.html create mode 100644 man/man4/index.html create mode 100644 man/man4/intro.html create mode 100644 man/man4/plumber.html create mode 100644 man/man4/ramfs.html (limited to 'man/man4') diff --git a/man/man4/9pserve.html b/man/man4/9pserve.html new file mode 100644 index 00000000..c9f2c3b7 --- /dev/null +++ b/man/man4/9pserve.html @@ -0,0 +1,79 @@ + +9pserve(4) - Plan 9 from User Space + + + + +
+
+
9PSERVE(4)9PSERVE(4) +
+
+

NAME
+ +
+ + 9pserve – announce and multiplex 9P service
+ +
+

SYNOPSIS
+ +
+ + 9pserve [ −v ] addr
+ +
+

DESCRIPTION
+ +
+ + On Plan 9, when a user-level file server mounts itself into a + name space or posts itself in /srv, the Plan 9 kernel multiplexes + the potentially many processes accessing the server into a single + 9P conversation. The user-level server need not concern itself + with how many processes are accessing it or with cleaning up + after a process when it exits unexpectedly. On Unix, 9pserve takes + the place of the Plan 9 kernel, multiplexing clients onto a single + server conversation and cleaning up after clients when they hang + up unexpectedly. +
+ + 9pserve announces a 9P service on addr and multiplexes any 9P + clients connecting to addr into a single conversation with a 9P + server on 9pserve’s standard input and output. When a client hangs + up, 9pserve flushes any outstanding 9P transactions and clunks + any outstanding fids belonging to the client. +
+ + 9pserve is typically not invoked directly; use post9pservice(3) + instead.
+ +
+

SEE ALSO
+ +
+ + intro(4), intro(9p)
+ +
+

SOURCE
+ +
+ + /usr/local/plan9/src/cmd/9pserve.c
+ +
+ +

 +
+
+ + +
+
+
+Space Glenda +
+
+ + diff --git a/man/man4/acme.html b/man/man4/acme.html new file mode 100644 index 00000000..ac310c13 --- /dev/null +++ b/man/man4/acme.html @@ -0,0 +1,268 @@ + +acme(4) - Plan 9 from User Space + + + + +
+
+
ACME(4)ACME(4) +
+
+

NAME
+ +
+ + acme – control files for text windows
+ +
+

SYNOPSIS
+ +
+ + acme [ −f varfont ] [ −F fixfont ] [ file ... ]
+ +
+

DESCRIPTION
+ +
+ + The text window system acme(1) serves a variety of files for reading, + writing, and controlling windows. Some of them are virtual versions + of system files for dealing with the virtual console; others control + operations of acme itself. When a command is run under acme, a + directory holding these files is posted as the 9P + service acme (using 9pserve(4)). +
+ + Some of these files supply virtual versions of services available + from the underlying environment, in particular the character terminal + files in Plan 9’s cons(3). (Unlike in Plan 9’s rio(1), each command + under acme sees the same set of files; there is not a distinct + /dev/cons for each window.) Other files are unique to + acme.
+ acmeis a subdirectory used by win (see acme(1)) as a mount point + for the acme files associated with the window in which win is + running. It has no specific function under acme itself.
+ consis the standard and diagnostic output file for all commands + run under acme. (Input for commands is redirected to /dev/null.) + Text written to cons appears in a window labeled dir/+Errors, + where dir is the directory in which the command was run. The window + is created if necessary, but not until text is + +
+ + actually written.
+ +
+ consctl
+ +
+ + Is an empty unwritable file present only for compatibility; there + is no way to turn off ‘echo’, for example, under acme.
+ +
+ index
+ +
+ + holds a sequence of lines of text, one per window. Each line has + 5 decimal numbers, each formatted in 11 characters plus a blank--the + window ID; number of characters (runes) in the tag; number of + characters in the body; a 1 if the window is a directory, 0 otherwise; + and a 1 if the window is modified, 0 + otherwise--followed by the tag up to a newline if present. Thus + at character position 5x12 starts the name of the window. If a + file has multiple zeroxed windows open, only the most recently + used will appear in the index file.
+ +
+ label
+ +
+ + is an empty file, writable without effect, present only for compatibility + with rio.
+ +
+ new   A directory analogous to the numbered directories (q.v.). Accessing + any file in new creates a new window. Thus to cause text to appear + in a new window, write it to /dev/new/body. For more control, + open /dev/new/ctl and use the interface described below. +
+ + +
+ + Each acme window has associated a directory numbered by its ID. + Window IDs are chosen sequentially and may be discovered by the + ID command, by reading the ctl file, or indirectly through the + index file. The files in the numbered directories are as follows.
+ addrmay be written with any textual address (line number, regular + expression, etc.), in the format understood by button 3 but without + the initial colon, including compound addresses, to set the address + for text accessed through the data file. When read, it returns + the value of the address that would next be read or + +
+ + written through the data file, in the format #m,#n where m and + n are character (not byte) offsets. If m and n are identical, + the format is just #m. Thus a regular expression may be evaluated + by writing it to addr and reading it back. The addr address has + no effect on the user’s selection of text. + +
+ bodyholds contents of the window body. It may be read at any byte + offset. Text written to body is always appended; the file offset + is ignored.
+ ctl   may be read to recover the five numbers as held in the index + file, described above, plus two more fields: the width of the + window in pixels and the name of the font used in the window. + Text messages may be written to ctl to affect the window. Each + message is terminated by a newline and multiple messages + +
+ + may be sent in a single write.
+ +
+ + addr=dot     Set the addr address to that of the user’s selected text + in the window.
+ clean        Mark the window clean as though it has just been written.
+ dirty        Mark the window dirty, the opposite of clean.
+ cleartag     Remove all text in the tag after the vertical bar.
+ del          Equivalent to the Del interactive command.
+ delete       Equivalent to the Delete interactive command.
+ dot=addr     Set the user’s selected text in the window to the text + addressed by the addr address.
+ dump commandSet the command string to recreate the window from + a dump file.
+ dumpdir directory
+ Set the directory in which to run the command to recreate the + window from a dump file.
+ get          Equivalent to the Get interactive command with no arguments; + accepts no arguments.
+ limit=addr   When the ctl file is first opened, regular expression + context searches in addr addresses examine the whole file; this + message restricts subsequent searches to the current addr address.
+ mark         Cancel nomark, returning the window to the usual state wherein + each modification to the body must be undone individually.
+ name name     Set the name of the window to name.
+ nomark       Turn off automatic ‘marking’ of changes, so a set of related + changes may be undone in a single Undo interactive command.
+ noscroll     Turn off automatic ‘scrolling’ of the window to show text + written to the body.
+ put          Equivalent to the Put interactive command with no arguments; + accepts no arguments.
+ scroll       Cancel a noscroll message, returning the window to the default + state wherein each write to the body file causes the window to + ‘scroll’ to display the new text.
+ show         Guarantee at least some of the selected text is visible on + the display.
+ +
+ +
+ datais used in conjunction with addr for random access to the + contents of the body. The file offset is ignored when writing + the data file; instead the location of the data to be read or + written is determined by the state of the addr file. Text, which + must contain only whole characters (no ‘partial runes’), written + to + +
+ + data replaces the characters addressed by the addr file and sets + the address to the null string at the end of the written text. + A read from data returns as many whole characters as the read + count will permit starting at the beginning of the addr address + (the end of the address has no effect) and sets the + address to the null string at the end of the returned characters.
+ +
+ event
+ +
+ + When a window’s event file is open, changes to the window occur + as always but the actions are also reported as messages to the + reader of the file. Also, user actions with buttons 2 and 3 (other + than chorded Cut and Paste, which behave normally) have no immediate + effect on the window; it is expected that + the program reading the event file will interpret them. The messages + have a fixed format: a character indicating the origin or cause + of the action, a character indicating the type of the action, + four free-format blank-terminated decimal numbers, optional text, + and a newline. The first and second numbers are + the character addresses of the action, the third is a flag, and + the final is a count of the characters in the optional text, which + may itself contain newlines. The origin characters are E for writes + to the body or tag file, F for actions through the window’s other + files, K for the keyboard, and M for the mouse. The + type characters are D for text deleted from the body, d for text + deleted from the tag, I for text inserted to the body, i for text + inserted to the tag, L for a button 3 action in the body, l for + a button 3 action in the tag, X for a button 2 action in the body, + and x for a button 2 action in the tag. + If the relevant text has less than 256 characters, it is included + in the message; otherwise it is elided, the fourth number is 0, + and the program must read it from the data file if needed. No + text is sent on a D or d message.
+ For D, d, I, and i the flag is always zero. For X and x, the flag + is a bitwise OR (reported decimally) of the following: 1 if the + text indicated is recognized as an acme built-in command; 2 if + the text indicated is a null string that has a non-null expansion; + if so, another complete message will follow describing the + expansion exactly as if it had been indicated explicitly (its + flag will always be 0); 8 if the command has an extra (chorded) + argument; if so, two more complete messages will follow reporting + the argument (with all numbers 0 except the character count) and + where it originated, in the form of a fully-qualified + button 3 style address.
+ For L and l, the flag is the bitwise OR of the following: 1 if + acme can interpret the action without loading a new file; 2 if + a second (post-expansion) message follows, analogous to that with + X messages; 4 if the text is a file or window name (perhaps with + address) rather than plain literal text. + For messages with the 1 bit on in the flag, writing the message + back to the event file, but with the flag, count, and text omitted, + will cause the action to be applied to the file exactly as it + would have been if the event file had not been open.
+ +
+ tag   holds contents of the window tag. It may be read at any byte + offset. Text written to tag is always appended; the file offset + is ignored.
+ +
+

SOURCE
+ +
+ + /usr/local/plan9/src/cmd/acme
+ +
+

SEE ALSO
+ +
+ + rio(1), acme(1)
+ +
+ +

 +
+
+ + +
+
+
+Space Glenda +
+
+ + diff --git a/man/man4/import.html b/man/man4/import.html new file mode 100644 index 00000000..e0eca5cb --- /dev/null +++ b/man/man4/import.html @@ -0,0 +1,107 @@ + +import(4) - Plan 9 from User Space + + + + +
+
+
IMPORT(4)IMPORT(4) +
+
+

NAME
+ +
+ + import – import 9P resources from another system
+ +
+

SYNOPSIS
+ +
+ + import [ −df ] [ −n ns ] [ −p prog ] [ −s service ] system
+ +
+

DESCRIPTION
+ +
+ + Import presents the 9P service service (default plumb) running + on system as a service on the local system, in the current name + space. +
+ + The −n option sets the remote name space directory where import + should expect to find service. If it is not specified, import + uses name of the local system’s name space directory. (Since name + space directories are conventionally inside /tmp, the path have + different meanings on the two systems.) +
+ + Import connects to system using ssh(1). It invokes import on the + remote system to carry out the remote side of the protocol. The + −p option specifies the path to import on the remote system, in + case it is not in the system search path. +
+ + The −d option turns on debugging. The −f option keeps import from + forking itself into the background, also useful for debugging.
+ +
+

EXAMPLE
+ +
+ + Suppose you run sam −r to the CPU server anna. Sam wants to talk + to a plumber on the local terminal, but the file names will refer + to files on anna. +
+ + To fix this problem, create a new name space directory and start + a new plumber on anna:
+ +
+ + remotens=/tmp/ns.`whoami`.on.`hostname`
+ ssh anna mkdir $remotens
+ ssh anna NAMESPACE=$remotens plumber
+ Now import that plumber to the local name space before starting + sam and 9term:
+ NAMESPACE=/tmp/ns.anna
+ mkdir $NAMESPACE
+ import −n $remotens −s plumb anna
+ sam &
+ 9term ssh anna &
+ +
+ +
+

SOURCE
+ +
+ + /usr/local/plan9/src/cmd/import.c
+ +
+

SEE ALSO
+ +
+ + 9pserve(4), intro(4)
+ +
+ +

 +
+
+ + +
+
+
+Space Glenda +
+
+ + diff --git a/man/man4/index.html b/man/man4/index.html new file mode 100644 index 00000000..bef356e8 --- /dev/null +++ b/man/man4/index.html @@ -0,0 +1,49 @@ + + +Manual Section 4 - Plan 9 from User Space + + + +
+
+ +
+
+
+ Manual Section 4 - Plan 9 from User Space +
+
+
intro(4)intro – introduction to file servers +
+
+
+
9pserve(4)9pserve – announce and multiplex 9P service +
+
+
+
acme(4)acme – control files for text windows +
+
+
+
import(4)import – import 9P resources from another system +
+
+
+
plumber(4)plumber – file system for interprocess messaging +
+
+
+
ramfs(4)ramfs – memory file system +
+
+ +
+
+
+Space Glenda +
+
+		 +
+ + diff --git a/man/man4/intro.html b/man/man4/intro.html new file mode 100644 index 00000000..ec2409c0 --- /dev/null +++ b/man/man4/intro.html @@ -0,0 +1,92 @@ + +intro(4) - Plan 9 from User Space + + + + +
+
+
INTRO(4)INTRO(4) +
+
+

NAME
+ +
+ + intro – introduction to file servers
+ +
+

DESCRIPTION
+ +
+ + A Plan 9 file server provides a file tree to processes. This section + of the manual describes servers that can be mounted in a name + space to give a file-like interface to interesting services. A + file server may be a provider of a conventional file system, with + files maintained on permanent storage, or it may also be a process + that synthesizes files in some manner. +
+ + In Plan 9, the kernel mount device mnt(3) acts as a client to + the 9P servers mounted in the current name space, translating + system calls such as open(2) into 9P transactions such as open(9p). + The kernel also multiplexes the potentially many processes onto + a single 9P conversation with each server. Finally, the kernel + provides each process with its own private name space which it + can customize at will. Modern Unix systems do not provide these + niceties, so the Unix port of these Plan 9 file servers provides + them via other means. +
+ + On Unix, 9P clients do not access servers via the traditional + file system call interface. Only the Unix name space can be accessed + that way. Instead, 9P clients use the 9pclient(3) library to connect + and interact directly with particular 9P servers. The 9p(1) command-line + client is useful for interactive use and in shell + scripts. +
+ + To preserve the façade of a single 9P conversation with each server, + 9P servers invoke 9pserve(4), typically via post9pservice(3). + 9pserve announces a 9P service at a particular network address + and multiplexes the clients that connect to that address onto + a single 9P conversation with the server. +
+ + Each ported program operates in a pseudo-name space that determines + which 9P servers it is using. The name space of a ported program + is represented by a directory containing Unix domain sockets, + one for each 9P server. The directory defaults to /tmp/ns.$USER.$DISPLAY, + meaning that all programs in an X + Windows login session share a single name space. Setting the $NAMESPACE + environment variable overrides this default. The namespace(1) + command prints the current name space directory. +
+ + Occasionally it is useful to be able to connect the input or output + of a standard Unix program to a file served by a 9P server. The + new openfd(9p) 9P transaction, which depends on file descriptor + passing, provides a sufficient workaround in many cases. 9pserve’s + implementation of openfd (see also fsopenfd in + 9pclient(3)) returns the read or write end of a pipe; a helper + process transfers data between the other end of the pipe and the + 9P server. Note that since the data is being transferred via a + pipe, 9P read and write errors cannot be passed on to the Unix + program. The Unix program sees only end-of-file or a closed pipe. + +
+ +

 +
+
+ + +
+
+
+Space Glenda +
+
+ + diff --git a/man/man4/plumber.html b/man/man4/plumber.html new file mode 100644 index 00000000..83e5943f --- /dev/null +++ b/man/man4/plumber.html @@ -0,0 +1,122 @@ + +plumber(4) - Plan 9 from User Space + + + + +
+
+
PLUMBER(4)PLUMBER(4) +
+
+

NAME
+ +
+ + plumber – file system for interprocess messaging
+ +
+

SYNOPSIS
+ +
+ + plumber [ −p plumbing ]
+ +
+

DESCRIPTION
+ +
+ + The plumber is a user-level file server that receives, examines, + rewrites, and dispatches plumb(7) messages between programs. Its + behavior is programmed by a plumbing file (default $HOME/lib/plumbing) + in the format of plumb(7). +
+ + Its services are posted via 9pserve(4) as plumb. and consist of + two pre-defined files, plumb/send and plumb/rules, and a set of + output ports for dispatching messages to applications. +
+ + Programs use fswrite (see 9pclient(3)) to deliver messages to + the send file, and fsread to receive them from the corresponding + port. For example, sam(1)’s plumb menu item or the B command cause + a message to be sent to plumb/send; sam in turn reads from, by + convention, plumb/edit to receive + messages about files to open. +
+ + A copy of each message is sent to each client that has the corresponding + port open. If none has it open, and the rule has a plumb client + or plumb start rule, that rule is applied. A plumb client rule + causes the specified command to be run and the message to be held + for delivery when the port is opened. A + plumb start rule runs the command but discards the message. If + neither start or client is specified and the port is not open, + the message is discarded and a write error is returned to the + sender. +
+ + The set of output ports is determined dynamically by the specification + in the plumbing rules file: a port is created for each unique + destination of a plumb to rule. +
+ + The set of rules currently active may be examined by reading the + file plumb/rules; appending to this file adds new rules to the + set, while creating it (opening it with OTRUNC) clears the rule + set. Thus the rule set may be edited dynamically with a traditional + text editor. However, ports are never deleted dynamically; + if a new set of rules does not include a port that was defined + in earlier rules, that port will still exist (although no new + messages will be delivered there).
+ +
+

FILES
+ +
+ + $HOME/lib/plumbing   default rules file
+ /usr/local/plan9/plumb
+ +
+ + +
+ + directory to search for files in include statements
+ +
+ +
+ plumb               mount name for plumber(4).
+ +
+

SOURCE
+ +
+ + /usr/local/plan9/src/cmd/plumb
+ +
+

SEE ALSO
+ +
+ + plumb(1), plumb(3), plumb(7)
+ +
+ +

 +
+
+ + +
+
+
+Space Glenda +
+
+ + diff --git a/man/man4/ramfs.html b/man/man4/ramfs.html new file mode 100644 index 00000000..7fb86f5a --- /dev/null +++ b/man/man4/ramfs.html @@ -0,0 +1,81 @@ + +ramfs(4) - Plan 9 from User Space + + + + +
+
+
RAMFS(4)RAMFS(4) +
+
+

NAME
+ +
+ + ramfs – memory file system
+ +
+

SYNOPSIS
+ +
+ + ramfs [ −i ] [ −S service ]
+ +
+

DESCRIPTION
+ +
+ + Ramfs starts a 9P file server keeping all files in memory. Initially + the file tree is empty. +
+ + By default ramfs posts its service as ramfs using 9pserve(4). + +
+ + The −S flag specifies an alternate service name for ramfs to use. + +
+ + The −i flag tells ramfs to use file descriptors 0 and 1 for its + communication channel rather than create a pipe. This makes it + possible to use ramfs as a file server on a remote machine: the + file descriptors 0 and 1 will be the network channel from ramfs + to the client machine. +
+ + This program is useful mainly as an example of how to write a + user-level file server. It can also be used to provide high-performance + temporary files.
+ +
+

SOURCE
+ +
+ + /usr/local/plan9/src/cmd/ramfs.c
+ +
+

SEE ALSO
+ +
+ + 9p(3), 9pserve(4)
+ +
+ +

 +
+
+ + +
+
+
+Space Glenda +
+
+ + -- cgit v1.2.3