attach(5) [plan9 man page]

ATTACH(5)							File Formats Manual							 ATTACH(5)

NAME

       attach, session, nop - messages to initiate activity

SYNOPSIS

       Tnop	 tag[2]
       Rnop	 tag[2]

       Tsession  tag[2] chal[8]
       Rsession  tag[2] chal[8] authid[28] authdom[48]

       Tattach	 tag[2] fid[2] uid[28] aname[28] ticket[72] auth[13]
       Rattach	 tag[2] fid[2] qid[8] rauth[13]

DESCRIPTION

       The nop request does nothing overt but may be used to synchronize the channel between two service hosts initially.

       The  session  request  is used to initialize a connection between a client and a server.  All outstanding I/O on the connection is aborted.
       The set of messages between session requests is called a session.  The host's user name (authid) and its  authentication  domain  (authdom)
       identify  the  key  to be used when authenticating to this host.  The exchanged challenges (chal) are used in the authentication algorithm.
       If authid is a null string no authentication is performed in this session.

       The tag should be NOTAG (value 0xFFFF) for a nop or session message.

       The attach message serves as a fresh introduction from a user on the client machine to a server.  The message identifies the user (uid) and
       may  select  the  file  tree to access (aname).	The ticket and auth arguments contains authorization data derived from the exchanged chal-
       lenges of the session message; see auth(6).

       As a result of the attach transaction, the client will have a connection to the root directory of the desired  file  tree,  represented	by
       fid.  An error is returned if fid is already in use.  The server's idea of the root of the file tree is represented by the returned qid.

ENTRY POINTS

       An  attach  transaction will be generated for kernel devices (see intro(3)) when a system call evaluates a file name beginning with Pipe(2)
       generates an attach on the kernel device pipe(3).  The mount system call (see bind(2)) generates an attach  messages  to  the  remote  file
       server.	 When  the  kernel  boots,  an attach is made to the root device, root(3), and then an attach is made to the requested file server
       machine.

SEE ALSO

       auth(6)

																	 ATTACH(5)

Check Out this Related Man Page

MNT(3)							     Library Functions Manual							    MNT(3)

NAME

       mnt - attach to 9P servers

SYNOPSIS

       #M

DESCRIPTION

       The  mount  driver  is used by the mount system call (but not bind; see bind(2)) to connect the name space of a process to the service pro-
       vided by a 9P server over a communications channel.  After the mount, system calls involving files in that portion of the name  space  will
       be converted by the mount driver into the appropriate 9P messages to the server.

       The  mount  system call issues session and attach(5) messages to the server to identify and validate the user of the connection.  Each dis-
       tinct user of a connection must mount it separately; the mount driver multiplexes the access of the various users and  their  processes	to
       the service.

       File-oriented system calls are converted by the kernel into messages in the 9P protocol.  Within the kernel, 9P is implemented by procedure
       calls to the various kernel device drivers.  The mount driver translates these procedure calls into remote procedure calls to be  transmit-
       ted as messages over the communication channel to the server.  Each message is implemented by a write of the corresponding protocol message
       to the server channel followed by a read on the server channel to get the reply.  Errors in the reply message are turned into  system  call
       error returns.

       A  read(2) or write system call on a file served by the mount driver may be translated into more than one message, since there is a maximum
       data size for a 9P message.  The system call will return when the specified number of bytes have been  transferred  or  a  short  reply	is
       returned.

       The string is an illegal file name, so this device can only be accessed directly by the kernel.

SEE ALSO

       bind(2)

SOURCE

       /sys/src/9/port/devmnt.c

BUGS

       When  mounting  a  service through the mount driver, that is, when the channel being multiplexed is itself a file being served by the mount
       driver, large messages may be broken in two.

																	    MNT(3)

Linux and UNIX Man Pages

attach(5) [plan9 man page]

Check Out this Related Man Page