glenda.party
term% ls -F
term% cat index.txt
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) iden‐
       tify the key to be used when authenticating  to  this  host.   The  ex‐
       changed 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 argu‐
       ments contains authorization data derived from the exchanged challenges
       of the session message; see auth(6).

       As a result of the attach transaction, the client will have  a  connec‐
       tion  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  in‐
       tro(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  ma‐
       chine.

SEE ALSO
       auth(6)

                                                                     ATTACH(5)