Open System Services Porting Guide (G06.24+, H06.03+)

OSS Porting Considerations
Open System Services Porting Guide—520573-006
6-22
Using Symbolic Links
•
For multiple readers and one writer in multiple processors, there can still be
significant performance improvement over using one processor, depending on the
mix of read versus write traffic.
When an application program calls one of the tdm_spawn or tdm_execve set of
function and specifies a processor different from the caller’s processor, this activity is
called open migration. In this case, some or all of the files that are open in the caller
must be opened by the new process created in the other processor. After these opens,
the calling process is terminated, causing all of its files to be closed. Creating
processes in another processor involves more file opens and the management of more
copies of data than with file operations within a single processor.
As needed, perform multiprocessor tasks in the OSS environment with multiple
processors. But be aware of the system costs and design trade-offs involved for your
operations, and take appropriate design steps to make your code run efficiently.
Using Symbolic Links
Similar to a hard link, a symbolic link allows a file to have multiple logical names. The
file named in a symbolic link actually contains the name of the file that contains the
data. A symbolic link permits links across file systems.
Symbolic links are implemented in the OSS environment, but only for OSS pathnames.
You cannot create symbolic links in the /G directory. The OSS functions supporting
symbolic links are symlink(), readlink(), and lstat(). Supporting
interoperability between the OSS and Guardian environments, these functions are
callable from Guardian processes and can be used with Guardian objects.
The symlink() function creates a symbolic link to a file. Symbolic links can be
created only in the OSS file system, but the file named in the symbolic link can be an
OSS file or a Guardian file (using /G syntax).
The readlink() function reads the value of a symbolic link by placing the contents of
the symbolic link named by the path parameter into the buffer parameter. To use
readlink(), the calling process must have execute (search) permission for the
directory containing the link. The readlink() function cannot be used on an object in
the Guardian file system (/G).
The lstat() function obtains information about the symbolic link whose name is
pointed to by the path parameter, or about any file pointed to by the path parameter.
When using lstat(), read, write, and execution permission for the specified file are
not required. For Guardian disk files, the lstat() and stat() functions are
functionally similar.
The functions that refer only to the symbolic link, rather than to the object to which the
link refers, are the link(), lstat(), mknod(), readlink(), remove(),
rename(), rmdir(), and unlink() functions.
Refer to the lstat(2), readlink(2), and symlink(2) reference pages, either
online or in the Open System Services System Calls Reference Manual.