URL
https://opencores.org/ocsvn/openrisc/openrisc/trunk
Subversion Repositories openrisc
[/] [openrisc/] [trunk/] [rtos/] [ecos-2.0/] [doc/] [html/] [ref/] [fileio-directories.html] - Rev 174
Compare with Previous | Blame | View Log
<!-- Copyright (C) 2003 Red Hat, Inc. --> <!-- This material may be distributed only subject to the terms --> <!-- and conditions set forth in the Open Publication License, v1.0 --> <!-- or later (the latest version is presently available at --> <!-- http://www.opencontent.org/openpub/). --> <!-- Distribution of the work or derivative of the work in any --> <!-- standard (paper) book form is prohibited unless prior --> <!-- permission is obtained from the copyright holder. --> <HTML ><HEAD ><TITLE >Directories</TITLE ><meta name="MSSmartTagsPreventParsing" content="TRUE"> <META NAME="GENERATOR" CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+ "><LINK REL="HOME" TITLE="eCos Reference Manual" HREF="ecos-ref.html"><LINK REL="UP" TITLE="File System Support Infrastructure" HREF="fileio.html"><LINK REL="PREVIOUS" TITLE="File Table" HREF="fileio-file-table.html"><LINK REL="NEXT" TITLE="Synchronization" HREF="fileio-synchronization.html"></HEAD ><BODY CLASS="CHAPTER" BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#840084" ALINK="#0000FF" ><DIV CLASS="NAVHEADER" ><TABLE SUMMARY="Header navigation table" WIDTH="100%" BORDER="0" CELLPADDING="0" CELLSPACING="0" ><TR ><TH COLSPAN="3" ALIGN="center" >eCos Reference Manual</TH ></TR ><TR ><TD WIDTH="10%" ALIGN="left" VALIGN="bottom" ><A HREF="fileio-file-table.html" ACCESSKEY="P" >Prev</A ></TD ><TD WIDTH="80%" ALIGN="center" VALIGN="bottom" ></TD ><TD WIDTH="10%" ALIGN="right" VALIGN="bottom" ><A HREF="fileio-synchronization.html" ACCESSKEY="N" >Next</A ></TD ></TR ></TABLE ><HR ALIGN="LEFT" WIDTH="100%"></DIV ><DIV CLASS="CHAPTER" ><H1 ><A NAME="FILEIO-DIRECTORIES">Chapter 23. Directories</H1 ><P >Filesystem operations all take a directory pointer as one of their arguments. A directory pointer is an opaque handle managed by the filesystem. It should encapsulate a reference to a specific directory within the filesystem. For example, it may be a pointer to the data structure that represents that directory (such as an inode), or a pointer to a pathname for the directory.</P ><P >The <TT CLASS="FUNCTION" >chdir()</TT > filesystem function pointer has two modes of use. When passed a pointer in the <TT CLASS="PARAMETER" ><I >dir_out</I ></TT > argument, it should locate the named directory and place a directory pointer there. If the <TT CLASS="PARAMETER" ><I >dir_out</I ></TT > argument is NULL then the <TT CLASS="PARAMETER" ><I >dir</I ></TT > argument is a previously generated directory pointer that can now be disposed of. When the infrastructure is implementing the <TT CLASS="FUNCTION" >chdir()</TT > function it makes two calls to filesystem <TT CLASS="FUNCTION" >chdir()</TT > functions. The first is to get a directory pointer for the new current directory. If this succeeds the second is to dispose of the old current directory pointer.</P ><P >The <TT CLASS="FUNCTION" >opendir()</TT > function is used to open a directory for reading. This results in an open file object that can be read to return a sequence of <SPAN CLASS="STRUCTNAME" >struct dirent</SPAN > objects. The only operations that are allowed on this file are <TT CLASS="FUNCTION" >read</TT >, <TT CLASS="FUNCTION" >lseek</TT > and <TT CLASS="FUNCTION" >close</TT >. Each read operation on this file should return a single <SPAN CLASS="STRUCTNAME" >struct dirent</SPAN > object. When the end of the directory is reached, zero should be returned. The only seek operation allowed is a rewind to the start of the directory, by supplying an offset of zero and a <TT CLASS="PARAMETER" ><I >whence</I ></TT > specifier of <TT CLASS="LITERAL" >SEEK_SET</TT >.</P ><P >Most of these considerations are invisible to clients of a filesystem since they will access directories via the POSIX <TT CLASS="FUNCTION" >opendir()</TT >, <TT CLASS="FUNCTION" >readdir()</TT > and <TT CLASS="FUNCTION" >closedir()</TT > functions.</P ><P >Support for the <TT CLASS="FUNCTION" >getcwd()</TT > function is provided by three mechanisms. The first is to use the <TT CLASS="LITERAL" >FS_INFO_GETCWD</TT > getinfo key on the filesystem to use any internal support that it has for this. If that fails it falls back on one of the two other mechanisms. If <TT CLASS="LITERAL" >CYGPKG_IO_FILEIO_TRACK_CWD</TT > is set then the current directory is tracked textually in <TT CLASS="FUNCTION" >chdir()</TT > and the result of that is reported in getcwd(). Otherwise an attempt is made to traverse the directory tree to its root using ".." entries.</P ><P >This last option is complicated and expensive, and relies on the filesystem supporting "." and ".." entries. This is not always the case, particularly if the filesystem has been ported from a non-UNIX-compatible source. Tracking the pathname textually will usually work, but might not produce optimum results when symbolic links are being used.</P ></DIV ><DIV CLASS="NAVFOOTER" ><HR ALIGN="LEFT" WIDTH="100%"><TABLE SUMMARY="Footer navigation table" WIDTH="100%" BORDER="0" CELLPADDING="0" CELLSPACING="0" ><TR ><TD WIDTH="33%" ALIGN="left" VALIGN="top" ><A HREF="fileio-file-table.html" ACCESSKEY="P" >Prev</A ></TD ><TD WIDTH="34%" ALIGN="center" VALIGN="top" ><A HREF="ecos-ref.html" ACCESSKEY="H" >Home</A ></TD ><TD WIDTH="33%" ALIGN="right" VALIGN="top" ><A HREF="fileio-synchronization.html" ACCESSKEY="N" >Next</A ></TD ></TR ><TR ><TD WIDTH="33%" ALIGN="left" VALIGN="top" >File Table</TD ><TD WIDTH="34%" ALIGN="center" VALIGN="top" ><A HREF="fileio.html" ACCESSKEY="U" >Up</A ></TD ><TD WIDTH="33%" ALIGN="right" VALIGN="top" >Synchronization</TD ></TR ></TABLE ></DIV ></BODY ></HTML >