coda.txt

ARM 嵌入式 系统 设计与实例开发 实验教材 二源码

                struct cfs_link_in {
                    ViceFid sourceFid;          /* cnode to link *to* */
                    ViceFid destFid;            /* Directory in which to place link */
                    char        *tname;         /* Place holder for data. */
                } cfs_link;



     oouutt
        empty

  DDeessccrriippttiioonn This call creates a link to the sourceFid in the directory
  identified by destFid with name tname.  The source must reside in the
  target's parent, i.e. the source must be have parent destFid, i.e. Coda
  does not support cross directory hard links.  Only the return value is
  relevant.  It indicates success or the type of failure.

  EErrrroorrss The usual errors can occur.0wpage

  44..1111..  ssyymmlliinnkk


  SSuummmmaarryy create a symbolic link

  AArrgguummeennttss

     iinn

                struct cfs_symlink_in {
                    ViceFid     VFid;          /* Directory to put symlink in */
                    char        *srcname;
                    struct coda_vattr attr;
                    char        *tname;
                } cfs_symlink;



     oouutt
        none

  DDeessccrriippttiioonn Create a symbolic link. The link is to be placed in the
  directory identified by VFid and named tname.  It should point to the
  pathname srcname.  The attributes of the newly created object are to
  be set to attr.

  EErrrroorrss

  NNOOTTEE The attributes of the target directory should be returned since
  its size changed.

  0wpage

  44..1122..  rreemmoovvee


  SSuummmmaarryy Remove a file

  AArrgguummeennttss

     iinn

                struct cfs_remove_in {
                    ViceFid     VFid;
                    char        *name;          /* Place holder for data. */
                } cfs_remove;



     oouutt
        none

  DDeessccrriippttiioonn  Remove file named cfs_remove_in.name in directory
  identified by   VFid.

  EErrrroorrss

  NNOOTTEE The attributes of the directory should be returned since its
  mtime and size may change.

  0wpage

  44..1133..  rrmmddiirr


  SSuummmmaarryy Remove a directory

  AArrgguummeennttss

     iinn

                struct cfs_rmdir_in {
                    ViceFid     VFid;
                    char        *name;          /* Place holder for data. */
                } cfs_rmdir;



     oouutt
        none

  DDeessccrriippttiioonn Remove the directory with name name from the directory
  identified by VFid.

  EErrrroorrss

  NNOOTTEE The attributes of the parent directory should be returned since
  its mtime and size may change.

  0wpage

  44..1144..  rreeaaddlliinnkk


  SSuummmmaarryy Read the value of a symbolic link.

  AArrgguummeennttss

     iinn

                struct cfs_readlink_in {
                    ViceFid VFid;
                } cfs_readlink;



     oouutt

                struct cfs_readlink_out {
                    int count;
                    caddr_t     data;           /* Place holder for data. */
                } cfs_readlink;



  DDeessccrriippttiioonn This routine reads the contents of symbolic link
  identified by VFid into the buffer data.  The buffer data must be able
  to hold any name up to CFS_MAXNAMLEN (PATH or NAM??).

  EErrrroorrss No unusual errors.

  0wpage

  44..1155..  ooppeenn


  SSuummmmaarryy Open a file.

  AArrgguummeennttss

     iinn

                struct cfs_open_in {
                    ViceFid     VFid;
                    int flags;
                } cfs_open;



     oouutt

                struct cfs_open_out {
                    dev_t       dev;
                    ino_t       inode;
                } cfs_open;



  DDeessccrriippttiioonn  This request asks Venus to place the file identified by
  VFid in its cache and to note that the calling process wishes to open
  it with flags as in open(2).  The return value to the kernel differs
  for Unix and Windows systems.  For Unix systems the Coda FS Driver is
  informed of the device and inode number of the container file in the
  fields dev and inode.  For Windows the path of the container file is
  returned to the kernel.
  EErrrroorrss

  NNOOTTEE Currently the cfs_open_out structure is not properly adapted to
  deal with the Windows case.  It might be best to implement two
  upcalls, one to open aiming at a container file name, the other at a
  container file inode.

  0wpage

  44..1166..  cclloossee


  SSuummmmaarryy Close a file, update it on the servers.

  AArrgguummeennttss

     iinn

                struct cfs_close_in {
                    ViceFid     VFid;
                    int flags;
                } cfs_close;



     oouutt
        none

  DDeessccrriippttiioonn Close the file identified by VFid.

  EErrrroorrss

  NNOOTTEE The flags argument is bogus and not used.  However, Venus' code
  has room to deal with an execp input field, probably this field should
  be used to inform Venus that the file was closed but is still memory
  mapped for execution.  There are comments about fetching versus not
  fetching the data in Venus vproc_vfscalls.  This seems silly.  If a
  file is being closed, the data in the container file is to be the new
  data.  Here again the execp flag might be in play to create confusion:
  currently Venus might think a file can be flushed from the cache when
  it is still memory mapped.  This needs to be understood.

  0wpage

  44..1177..  iiooccttll


  SSuummmmaarryy Do an ioctl on a file. This includes the pioctl interface.

  AArrgguummeennttss

     iinn

                struct cfs_ioctl_in {
                    ViceFid VFid;
                    int cmd;
                    int len;
                    int rwflag;
                    char *data;                 /* Place holder for data. */
                } cfs_ioctl;



     oouutt


                struct cfs_ioctl_out {
                    int len;
                    caddr_t     data;           /* Place holder for data. */
                } cfs_ioctl;



  DDeessccrriippttiioonn Do an ioctl operation on a file.  The command, len and
  data arguments are filled as usual.  flags is not used by Venus.

  EErrrroorrss

  NNOOTTEE Another bogus parameter.  flags is not used.  What is the
  business about PREFETCHING in the Venus code?


  0wpage

  44..1188..  rreennaammee


  SSuummmmaarryy Rename a fid.

  AArrgguummeennttss

     iinn

                struct cfs_rename_in {
                    ViceFid     sourceFid;
                    char        *srcname;
                    ViceFid destFid;
                    char        *destname;
                } cfs_rename;



     oouutt
        none

  DDeessccrriippttiioonn  Rename the object with name srcname in directory
  sourceFid to destname in destFid.   It is important that the names
  srcname and destname are 0 terminated strings.  Strings in Unix
  kernels are not always null terminated.

  EErrrroorrss

  0wpage

  44..1199..  rreeaaddddiirr


  SSuummmmaarryy Read directory entries.

  AArrgguummeennttss

     iinn

                struct cfs_readdir_in {
                    ViceFid     VFid;
                    int count;
                    int offset;
                } cfs_readdir;




     oouutt

                struct cfs_readdir_out {
                    int size;
                    caddr_t     data;           /* Place holder for data. */
                } cfs_readdir;



  DDeessccrriippttiioonn Read directory entries from VFid starting at offset and
  read at most count bytes.  Returns the data in data and returns
  the size in size.

  EErrrroorrss

  NNOOTTEE This call is not used.  Readdir operations exploit container
  files.  We will re-evaluate this during the directory revamp which is
  about to take place.

  0wpage

  44..2200..  vvggeett


  SSuummmmaarryy instructs Venus to do an FSDB->Get.

  AArrgguummeennttss

     iinn

                struct cfs_vget_in {
                    ViceFid VFid;
                } cfs_vget;



     oouutt

                struct cfs_vget_out {
                    ViceFid VFid;
                    int vtype;
                } cfs_vget;



  DDeessccrriippttiioonn This upcall asks Venus to do a get operation on an fsobj
  labelled by VFid.

  EErrrroorrss

  NNOOTTEE This operation is not used.  However, it is extremely useful
  since it can be used to deal with read/write memory mapped files.
  These can be "pinned" in the Venus cache using vget and released with
  inactive.

  0wpage

  44..2211..  ffssyynncc


  SSuummmmaarryy Tell Venus to update the RVM attributes of a file.

  AArrgguummeennttss

     iinn

                struct cfs_fsync_in {
                    ViceFid VFid;
                } cfs_fsync;



     oouutt
        none

  DDeessccrriippttiioonn Ask Venus to update RVM attributes of object VFid. This
  should be called as part of kernel level fsync type calls.  The
  result indicates if the syncing was successful.

  EErrrroorrss

  NNOOTTEE Linux does not implement this call. It should.

  0wpage

  44..2222..  iinnaaccttiivvee


  SSuummmmaarryy Tell Venus a vnode is no longer in use.

  AArrgguummeennttss

     iinn

                struct cfs_inactive_in {
                    ViceFid VFid;
                } cfs_inactive;



     oouutt
        none

  DDeessccrriippttiioonn This operation returns EOPNOTSUPP.

  EErrrroorrss

  NNOOTTEE This should perhaps be removed.

  0wpage

  44..2233..  rrddwwrr