intro(4) - Plan 9 from User Space

From adc93f6097615f16d57e8a24a256302f2144ec4e Mon Sep 17 00:00:00 2001 From: rsc Date: Fri, 14 Jan 2005 17:37:50 +0000 Subject: cut out the html - they're going to cause diffing problems. --- man/man4/intro.html | 92 ----------------------------------------------------- 1 file changed, 92 deletions(-) delete mode 100644 man/man4/intro.html (limited to 'man/man4/intro.html') diff --git a/man/man4/intro.html b/man/man4/intro.html deleted file mode 100644 index ec2409c0..00000000 --- a/man/man4/intro.html +++ /dev/null @@ -1,92 +0,0 @@ - -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. - -
- -

- - -

		-
	- - - -

- - -- cgit v1.2.3