| PUFFS_PATH(3) | Library Functions Manual | PUFFS_PATH(3) | 
puffs_path —
#include <puffs.h>
int
  
  pu_pathbuild_fn(struct puffs_usermount
    *pu, const struct puffs_pathobj *po_dir,
    const struct puffs_pathobj *po_comp,
    size_t offset, struct puffs_pathobj
    *po_new);
int
  
  pu_pathtransform_fn(struct
    puffs_usermount *pu, const struct puffs_pathobj
    *po_base, const struct puffs_cn *pcn,
    struct puffs_pathobj *po_new);
int
  
  pu_pathcmp_fn(struct puffs_usermount
    *pu, struct puffs_pathobj *po1,
    struct puffs_pathobj *po2, size_t
    checklen, int checkprefix);
void
  
  pu_pathfree_fn(struct
    puffs_usermount *pu,
    struct puffs_pathobj
    *po);
int
  
  pu_namemod_fn(struct puffs_usermount
    *pu, struct puffs_pathobj *po_dir,
    struct puffs_cn *pcn);
struct puffs_pathobj *
  
  puffs_getrootpathobj(struct
    puffs_usermount *pu);
The features described here are enabled by passing
    PUFFS_FLAG_BUILDPATH to
    puffs_init(). This facility requires to use puffs
    nodes to store the contents of the pathname. Either the address of the
    operation cookie must directly be that of the puffs node, or
    puffs_set_cmap() must be used to set a mapping
    function from the cookie to the puffs node associated with the cookie.
    Finally, the root node for the file system must be set using
    puffs_setroot() and the root path object retrieved
    using puffs_getrootpathobj() and initialized.
There are two different places a filename can be retrieved from.
    It is available for each puffs node after the node has been registered with
    the framework, i.e. after the routine creating the node
    returns. In other words, there is a window between the node is created and
    when the pathname is available and multithreaded file systems must take this
    into account. The second place where a pathname is available is from the
    componentname struct puffs_pcn in operations which are
    passed one. These can be retrieved using the convenience macros
    PNPATH() and PCNPATH() for
    node and componentname, respectively. The type of object they return is
    void *.
By default the framework manages "regular" filenames,
    which consist of directory names separated by "/" and a final
    component. If the file system wishes to use pathnames of this format, all it
    has to do it enable the feature. Everything else, including bookkeeping for
    node and directory renames, is done by the library. The callback routines
    described next provide the ability to build non-standard pathnames. A
    pu_foo_fn() callback is set using the
    puffs_set_foo() routine.
This manual page is still unfinished. Please take a number and wait in line.
| December 27, 2007 | NetBSD 10.0 |