Lines Matching full:in
11 named Venus, as well as tools to manipulate ACLs, to log in, etc. The
12 client needs to have the Coda filesystem selected in the kernel
148 11.. IInnttrroodduuccttiioonn
152 A key component in the Coda Distributed File System is the cache
156 When processes on a Coda enabled system access files in the Coda
157 filesystem, requests are directed at the filesystem layer in the
175 Historically Coda was implemented in a BSD file system in Mach 2.6.
180 filesystem driver for Coda in a BSD system. However, other operating
189 kernel should be documented in great detail. This is the aim of this
194 22.. SSeerrvviicciinngg CCooddaa ffiilleessyysstteemm ccaallllss
196 The service of a request for a Coda file system service originates in
199 …l_o_s_e_, _c_r_e_a_t_e_, _m_k_d_i_r_, _r_m_d_i_r_, _c_h_m_o_d in a Unix
200 context. Similar calls exist in the Win32 environment, and are named
203 Generally the operating system handles the request in a virtual
204 filesystem (VFS) layer, which is named I/O Manager in NT and IFS
205 manager in Windows 95. The VFS is responsible for partial processing
207 service parts of the request. Usually the information in the path
208 assists in locating the correct FS drivers. Sometimes after extensive
209 pre-processing, the VFS starts invoking exported routines in the FS
217 as applicable in the operating system. These differ very significantly
227 must allow Venus to manage message traffic. In particular Venus must
246 Venus replies the response is passed back to the caller in unmodified
251 and results in an efficient system. However, Venus may acquire
254 to the Coda FS layer to request flushes or updates in the cache. The
276 FS Driver in kernel memory on behalf of P and copied to user memory in
282 number, the size of the request and a pointer to the data in kernel
285 field is used in the message to precisely record the status of the
288 synchronization objects. In the upcall routine the message structure
289 is filled in, flags are set to 0, and it is placed on the _p_e_n_d_i_n_g
291 data buffer; its structure will be described in the next section.
294 created, and implemented using available synchronization objects in
295 the OS. This notification is done in the upcall context of the process
297 in upcall. The (kernel mode) processing of P in the filesystem
299 the calling thread in P is blocked in upcall. A pointer in the
305 call. This action finishes in the kernel by putting the message on the
317 WRITTEN. Finally, the FS driver unblocks P (still in the kernel
330 up in upcall by a signal from some other source (for example an
331 attempt to terminate P) or as is normally the case by Venus in its
332 sendmsg_to_kernel call. In the normal case, the upcall routine will
344 In case P is woken up by a signal and not by Venus, it will first look
349 signals are put in the queue at the head, and read first by Venus. If
353 extra field "handle_signals" could be added in the message structure
367 In Windows NT and the DPMI Windows 95 implementation a DeviceIoControl
373 object in NT and a semaphore in Windows 95.
377 44.. TThhee iinntteerrffaaccee aatt tthhee ccaallll lleevveell
382 outputArgs. In pseudo BNF form the structures take the following
393 <union "in" of call dependent parts of inputArgs>
425 unsigned integers. It also defines group membership in an array. On
438 NNOOTTEE It is questionable if we need CodaCreds in Venus. Finally Venus
445 directory in the Coda filesystem within a _c_e_l_l. (-- A _c_e_l_l is a
467 support for device files (currently not present in Coda).
494 u_quad_t va_size; /* file size in bytes */
511 44..22.. TThhee ppiiooccttll iinntteerrffaaccee
519 The kernel involvement in this is limited to providing the facility to
520 open and close and pass the ioctl message _a_n_d to verify that a path in
521 the pioctl data buffers is a file in a Coda filesystem.
537 caddr_t in, out; /* Data to be transferred in, or out */
559 iinn empty
573 indicating the difficulty Venus encountered in locating the root of
581 SSuummmmaarryy Find the ViceFid and type of an object in a directory if it
586 iinn
608 difficulty was encountered in finding it (e.g. due to disconnection).
618 not be put in the kernel name cache.
632 iinn
658 "inode" or "FileHandle". A significant improvement in performance on
662 The vattr structure included in the input arguments is superfluous and
674 iinn
688 in BSD style. Attributes not to be changed are set to -1, apart from
706 iinn
737 iinn
760 The file will be created in the directory identified by VFid, its name
762 be returned if the file already exists. If the size field in attr is
778 This create call differs from the Unix one in that it is not invoked
781 under Unix. There should be no flags argument; this is used in open
796 iinn
817 Only the mode field in the input parameters is used for creation.
831 44..1100.. lliinnkk
838 iinn
842 ViceFid destFid; /* Directory in which to place link */
851 DDeessccrriippttiioonn This call creates a link to the sourceFid in the directory
852 identified by destFid with name tname. The source must reside in the
859 44..1111.. ssyymmlliinnkk
866 iinn
869 ViceFid VFid; /* Directory to put symlink in */
880 DDeessccrriippttiioonn Create a symbolic link. The link is to be placed in the
899 iinn
911 DDeessccrriippttiioonn Remove file named cfs_remove_in.name in directory
928 iinn
950 44..1144.. rreeaaddlliinnkk
957 iinn
989 iinn
1008 VFid in its cache and to note that the calling process wishes to open
1009 it with flags as in open(2). The return value to the kernel differs
1011 informed of the device and inode number of the container file in the
1030 iinn
1050 fetching the data in Venus vproc_vfscalls. This seems silly. If a
1051 file is being closed, the data in the container file is to be the new
1052 data. Here again the execp flag might be in play to create confusion:
1065 iinn
1093 business about PREFETCHING in the Venus code?
1105 iinn
1119 DDeessccrriippttiioonn Rename the object with name srcname in directory
1120 sourceFid to destname in destFid. It is important that the names
1121 srcname and destname are 0 terminated strings. Strings in Unix
1135 iinn
1156 read at most count bytes. Returns the data in data and returns
1157 the size in size.
1174 iinn
1198 These can be "pinned" in the Venus cache using vget and released with
1210 iinn
1231 44..2222.. iinnaaccttiivvee
1234 SSuummmmaarryy Tell Venus a vnode is no longer in use.
1238 iinn
1264 iinn
1307 iinn
1324 name. The fid is returned in VFid.
1329 removed since it causes a jungle of pointers in the VFS mounting area.
1341 iinn irrelevant
1358 SSuummmmaarryy expands something in a dynamic set.
1362 iinn irrelevant
1382 iinn Not documented.
1405 iinn none
1420 what state changes in Venus take place after an upcall for which the
1426 55.. TThhee mmiinniiccaacchhee aanndd ddoowwnnccaallllss
1436 internal file handles (called vnodes in BSD, inodes in Linux and
1437 FileHandles in Windows) with the ViceFid's which Venus maintains. The
1438 reason is that frequent translations back and forth are needed in
1453 The lookup call in the Coda FS Driver may request the cnode of the
1466 55..11.. IINNVVAALLIIDDAATTEE
1497 DDeessccrriippttiioonn Remove all entries in the cache carrying the Cred. This
1516 NNOOTTEE Call is not named correctly in NetBSD and Mach. The minicache
1533 DDeessccrriippttiioonn Remove all entries in the cache lying in a directory
1551 DDeessccrriippttiioonn Remove all entries in the cache carrying the cred and VFid
1552 as in the arguments. This downcall is probably never issued.
1588 DDeessccrriippttiioonn This routine replaces a ViceFid in the name cache with
1595 66.. IInniittiiaalliizzaattiioonn aanndd cclleeaannuupp
1613 much more delicate. User processes hold reference counts in Coda
1668 NNOOTTEE NetBSD in particular but also Linux have not implemented the