RTEMS文件系统(4)：系统调用开发信息(上)

最新推荐文章于 2023-11-28 15:37:32 发布

coolbacon

最新推荐文章于 2023-11-28 15:37:32 发布

阅读量1.9k

点赞数 1

分类专栏： RTEMS 资料文章标签： descriptor 网络 permissions comments path access

RTEMS 资料专栏收录该内容

18 篇文章 3 订阅

订阅专栏

4 system Call Development Notes
这一套例程代表应用程序中~RTEMS~文件系统为文件和目录提供的接口。
所有函数都与~POSIX~标准兼容，如果一个特定的接口已经实现。
下面的列表列出的例程是应用程序接口一部分。

access()
chdir()
chmod()
chown()
close()
closedir()
dup()
dup2()
fchmod()
fcntl()
fdatasync()
fpathconf()
fstat()
ioctl()
link()
lseek()
mkdir()
mkfifo()
mknod()
mount()
open()
opendir()
pathconf()
read()
readdir()
unmount()

下面的小将提供每一个函数与开发相关的信息。

4.1 access
FILE: access.c
文件：access.c

处理：
此函数是基于~stat()~函数的。它获取指定文件的当前状态信息，然后根据传递给这个函数的模式参数判断调用者否有能力访问该文件(读、写或执行)。

开发注释：此函数是基于~stat()~函数之上的。只要返回的结构中的~st_mode~字段遵循的标准~UNIX~惯例，这个函数不需要修改也应该支持其他文件系统。

4.2 chdir
文件：chdir.c

处理：这个函数将判断我们试图改变当前路径的路径名是否存在并且是否为一个目录。
如果这些条件满足，当前目录全局指示~(rtems_filesystem_current)~被设置为由~rtems_filesystem_evaluate_path()~函数
返回的~rtems_filesystem_location_info_t~结构定义的变量。

开发注释：此函数是基于~rtems_filesystem_evaluate_path()~函数和文件系统指定的~OP~表中的~node_type()~函数。
每个文件系统必须提供~node_type()~函数，因为它访问文件系统的节点信息，以判断该节点是以下哪种类型：

RTEMS_FILESYSTEM_DIRECTORY
RTEMS_FILESYSTEM_DEVICE
RTEMS_FILESYSTEM_HARD_LINK
RTEMS_FILESYSTEM_MEMORY_FILE

必须承认这种节点管理信息的形式可以适应各种不同的文件系统的具体实现。
RTEMS~有一个特殊结构的全局变量，维护当前的目录位置。
这个全局变量的类型是~rtems_filesystem_location_info_t，名字为~rtems_filesystem_current。
这个结构并不总是有效的。为了确定结构是有效的，你必须先测试此结构中的~node_access~字段。
如果指针为~NULL，那么这个结构并不包含有效的当前目录的指示。

4.3chmod
文件：chmod.c

处理：此函数是基于~open()、fchmod()~和~close()~函数。
只要保持~mode_t~值的标准解释不变，该函数不需要修改即可支持其他的文件系统。

开发注释：该函数首先确定可以使用读/写访问打开所选的文件。
所选相关路径允许模式的修改需要这样打开文件。
fchmod()~函数使用~open()~函数返回的整数文件指针来实际修改路径的模式。
修改模式后，会关闭被打开的文件描述符。

4.4 chown
文件：chown.c

处理：此函数是建立在~rtems_filesystem_evaluate_path()~和由文件系统的~OPS~表中指定的~chown()~函数基础上的。

开发注释：rtems_filesystem_evaluate_path()~被用于确定指定的路径是否存在。
如果从其中获取到一个~rtems_filesystem_location_info_t~结构的数据，则允许调用函数使用这个文件系统的~OPS~表。
chown()~函数在~OPS~表中有可能没有定义。
在调用~chown()~函数之前需要检查~OPS~表中的~chown()~选项是否有效(不等于~NULL)。
如果~chown()~函数在~OPS~表中定义，使用路径评估例程返回的~rtems_filesystem_location_info_t~结构类型的变量，期望的拥有者和用户组
做为参数调用该函数。

4.5close
文件：
close.c

处理：这个函数将允许将网络连接和文件系统设备关闭。
如果文件描述符与一个网络设备相关，将从先前注册的网络函数表(rtems_libio_handlers)中选出适当的网络函数进行调用。
如果文件描述符引用一个文件系统中的入口，将使用设备放置在文件控制块~(rtems_libio_t~结构)~里的信息选择合适的处理程序。

开发注释：rtems_file_descriptor_type~检查一些文件描述符索引的高位部分。
如果它发现在文件描述符索引的高比特位被设置，该设备是网络设备的引用。
网络设备的处理程序是从一个特殊的注册表~(rtems_libio_handlers)~中获取的，它是在网络初始化时设置的。
调用网络处理程序，网络处理程序的状态将被返回给调用函数。
如果在文件描述符索引的高比特位没有被设置，文件描述符引用的是一个~RTEMS~文件系统的元素。
以下执行序列将会应用于任何文件系统的文件描述：

使用~rtems_libio_iop()~函数为文件描述获取~rtems_libio_t~结构；
使用~rtems_libio_check_fd()~对文件描述符进行范围检查；
确认是否在处理程序选择表中有一个真实的函数为文件系统和节点类型选择处理~close()~操作。
这通常是为了避免执行尚未实现的函数；
如果定义了该函数，调用它的时候使用文件控制块的指针作为它的参数；
与打开文件描述符相关联的文件控制块被使用~rtems_libio_free()~函数标记为自由(???)；
关闭处理程序返回代码给调用它的程序。

4.6 closedir
文件：closedir.c

处理：这个代码从~BSD~小组获取。此例程必须清理跟踪打开目录所需要的内存资源。
该代码是基于~close()~函数和标准内存~free()~函数。
它不需要改变即支持其他文件系统。

开发注释：该例程更改文件描述符和索引成为一个目录结构，使其变为一个无效的文件描述符。
显然，即将被释放的内存在重新申请之前仍可能被引用。
dd_buf~结构的内存将在包含指向~dd_buf~区域的指针的控制结构之前被重新分配。
目录控制内存被重新分配。
close()~函数用于释放文件描述符索引。

4.7 dup() Unimplemented
File:
dup.c
Processing:
Development Comments:

4.8 dup2() Unimplemented
File:
dup2.c
Processing:
Development Comments:

4.9 fchmod
文件：fchmod.c

处理：此函数将改变一个文件系统的节点的权限。它是基于以下的函数和宏：

rtems_file_descriptor_type()；
rtems_libio_iop()；
rtems_libio_check_fd()；
rtems_libio_check_permissions()；
与这个文件描述符关联的文件控制块中处理例程表所引用的~fchmod()~函数。

开发注释：
例程将尝试去检查文件描述符索引是否与网络连接相关联。
如果是，则从这个例程返回一个错误。
文件描述符索引号是用来获取相关的文件控制块。
文件描述符的值已被检查了范围。
检查文件控制块以确定是否拥有对它的写权限，让我们可改变文件的模式。
测试文件控制块所引用的处理程序表中是否包含~fchmod()~处理函数。
如果没有，将返回一个错误给调用例程。
如果~fchmod()~函数存在，程序会以文件控制块和所需的模式作为参数调用该函数。

4.10 fcntl
文件：fcntl.c

处理：
目前函数仅与文件控制块交互。如果文件控制块的结构和相关字段的含义没有改变，
在其他文件系统的实现中部分~fcntl()~的实现应保持不变。

开发注释：
已经实现的命令只有~F_SETFD~和~F_GETFD。
该命令操纵文件描述符索引相关联的文件控制块中的~flags~字段的~LIBIO_FLAGS_CLOSE_ON_EXEC~比特位。

该函数的目前实现执行的操作顺序如下：