Introduction
Two types of system services exist: request-based system services, and system-common services. The two are somewhat similar, in that each performs a service for a client application, but the methods by which the two types perform the service are quite different.
Request-based system services are described in the previous chapter.
This chapter describes system-common services.
Request-Based vs. System-Common Services
Request-based system services and system-common services are suited to different types of work. This section describes how the system-common model differs from the request-based model, and gives guidelines for deciding which model is more appropriate for a given task.
The System-Common Model
The system-common model is different from the request-based model in one major way.
In the request-based model, the client sends a request to the service. The service then takes over control of the processor and performs its work.
While the system service executes, the client process waits. When the service has finished, it sends a response to the client. This allows the client to regain control of the processor and begin executing again.
In the system-common model, there are no requests or responses. When the system-common service installs itself, it tells the operating system the Writing System-Common Services 9-1
entry point and parameters of each of its system-common procedures.
After it has defined its system-common procedures to the operating system, the service simply waits to deinstall. It performs no more work, itself.
To use a system-common procedure, clients simply call the procedure as if it were part of the client program. The operating system detects that the called procedure is actually a system-common procedure, and transfers the client's execution point to the beginning of the system-common procedure.
The client never gives up control of the processor. The system-common procedure executes as part of the client process. Then, when the system-common procedure returns, the operating system resets the client's execution point to the appropriate place in the client program.
Figure 9-1 shows the threads of execution in a request-based system service model, and in the system-common service model.
Client
Request
I
System Service
Response
Request-Based System Service Model
Client
Call System-Common Procedure
Return
System-Common Service Model
Figure 9-1. Threads of Execution in System Services 9-2 eTOS/ Open Programming Practices and Standards - Part I
In summary, a system-common service consists of one or more globally accessible procedures, which are managed by the operating system. When a client calls a system-common procedure, that procedure executes as if it were part of the client application. The system-common service itself performs no work other than installing and deinstalling the procedures it controls.
Special Features of System-Common Procedures
System-common procedures have two features that give them an advantage over request-based system services under some circumstances:
• System-common services eliminate the need to define requests, except for the service's deinstallation request .
• Because system-common services do not use requests, they eliminate the overhead associated with the request mechanism.
Eliminating the need to define requests is mainly a point of convenience.
This feature can also make system-common services easier to install on a hard disk, because they often eliminate the need to merge request files.
Because system-common procedures eliminate the task switches and other overhead required by the request mechanism, they have a significant performance advantage over request-based system services. This can save a substantial amount of execution time, especially for short procedures.
Requirements for System-Common Procedures
Because system-common procedures execute as if they were part of the client application, there are several requirements they must meet.
• A system-common service must reside on the same processor as its client.
• All system-common procedures must be reentrant.
• System-common services must use selectors from the processor's Global Descriptor Table (GDT).
Writing System-Common Services 9-3
\
The major restriction on system-common procedures is that a system-common service must reside on the same processor as its client.
Because system-common procedures do not use the request mechanism, there is no way for a client to communicate with a service that resides on different processor.
All system-common procedures must also be reentrant. A reentrant procedure is one which may be entered repeatedly, and may be entered before prior executions of the same procedure have been completed.
Neither its external parameters nor its instructions can be modified during its execution.
System-common procedures must be reentrant because clients execute the actual code' in the system-common procedure, and a system-common service can have multiple clients. Therefore, one client may begin I executing a procedure before the previous client has finished executing it.
All system-common procedures must use the processor's Global Descriptor Table (GDT). This allows the client to execute code that resides in the system-common procedure without requiring the operating system to perform any selector aliasing.
In order for a program to use the processor's GDT, the program must be linked using the Bind command, with a run file mode of "GDTProtected."
Deciding Which Type of Service is Appropriate for Your Task
Request-based services and system-common services are each suited to different circumstances. When clients may need to access the system service across the cluster or over a network, the service must be request-based. However, if the service will always reside on the same processor as its client, a system-common service can provide better performance.
9-4 eTOS/ Open Programming Practices and Standards - Part I
Writing System-Common Procedures
A system-common service can be thought of as a collection of independent procedures. Each procedure has its own entry point, and has no necessary relationship to any other procedure. In practice, the procedures in a system-common service are usually related to each other, because they usually perfonn similar or related operations.
The procedures in a system-common service may also reference the service's global data, to obtain status or other information. If a system-common procedure needs access to the service's global data, the procedure needs to load the service's global data segment address in its data segment register. If the service is compiled using the Large model of computation, this occurs automatically. See your programming language documentation for more information.
System-common procedures should generally not write to the service's global data, because that would violate the rules for reentrance.
System-common procedures should only write to local variables and to memory addresses passed as parameters by the client.
Listing 9-1 shows an example of a system-common procedure which performs a task similar to the one in the request-based system service from Chapter 8. The pragma, CTOS_CALLING_CONVENTIONS, informs the compiler that the procedure should use the standard CTOS calling convention, described in Part II of this manual, instead of the C language calling convention.
The variables rgMsgRet and cbMsgRet are a character string and its size, located in the service's global data. .
Writing System-Common Services 9-5
/* Process calls to our system-common procedure */
pragma Calling_convention(CTOS_CALLING_CONVENTIONS);
ErcType GetFooText(Pointer pbDataRet, Word cbDataRet, Pointer psDataRet)
[
Word i=O;
/* get the maximum size of the message */
if(cbDataRet
<
cbMsgRet) i cbDataRet;else
i = cbMsgRet;
/* put the message in the user's buffer */
memcpy(pbDataRet, rgMsgRet, i);
*«Word *) psDataRet) = i;
/* return ercOK */
return(O);
}
pragma Calling_convention();
Listing 9-1. Sample System-Common Procedure