Os file
From Java4c
(first) |
m (Protected "Os file" ([edit=autoconfirmed] (indefinite) [move=autoconfirmed] (indefinite))) |
Revision as of 10:14, 6 March 2011
Situation in embedded software
A file system how it is known from the PC-based software in C is not present in some embedded devices.
But a handling of special files may be possible. There may be present only a few files with given names, or some files in only one directory level which are stored in the RAM, a flash file system, a remote file system etc.
User software should handle with files, independently how it is deployed in the given hardware platform. If there are only special files, the user software should regard this situation using the given special file-paths while open it. But the user software should not depend on the hardware implementation of the file system. All algorithm should be able to test on PC-platform.
Situation of standardizing in C
The old C knows two standard to access files:
- Lo-level file-io using open, read, write with a int handle. This was the originally intension in C. This concept founds the stream-handling of UNIX using pipes, standard- and error.output on console etc.
- Buffered file-io using fopen, fread, fwrite, fflush with a structured file handle named FILE* defined in < stdio.h>. This was a second stage of file handling in C.
The interface between the linux-core and the library-layer is adequate to the lo-level-file-system.
But in C-programming only the buffered file-io is usual now. The C99-standard doesn't know the routines of the lo-level-file-io. The buffered file-io regards the stdout, stdin and stderr for piping command line applications too. But they are not the int-values 0..2. Rather than they are special FILE-objects supported by the std-library.
Any C-compiler at any embedded system may offer this file-io-standard-routines and data, but sometimes not in that way how the hardware implements it really. To access the file system which is supported by special packages the routines of the special package should be used instead. The methods are provided in adequate interfaces with adequate names of the routines, but not identical. Often the file-system-component is not integrated in the standard library of the compiler.
Using os_file.h instead file handling with stdio.h
How it is described in the chapter above, the standard-file-handling doesn't resolve the real expected functionality. Thats why the user programming should not use the standard-file-handling but the os_file-handling. The OSAL-layer adapts the real file handling of the given environment. It can do it because it is a module associated to the users system component, not only associated to the compiler provider.
Sometimes the handling of files is wrapped with functionality of a higher level than the C-standard-file-io. The user uses this wrapper instead the more lo-level C-functions. Inside the wrapper the os_file-routines are called. In that kind the user hasn't any cohesion to the os_file or standard-file handling immediately. The usage of wrappers provides a higher-level interface for the user programming.
