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)