Subsystem and Device Driver Starting

Entry routines like the following are defined for subsystems and device drivers.

ER main( INT ac, UB *av[] )
        if ( ac >= 0 ) {
                /* Subsystem/device driver start processing */
        } else {
                /* Subsystem/device driver termination processing */

        return ercd;

This entry routine simply performs startup processing or termination processing for a subsystem or device driver and does not provide any actual service. It must return to its caller as soon as the startup processing or termination processing is performed. An entry routine must perform its processing as quickly as possible and return to its caller.

An entry routine is called by the task which belongs to the system resource group at the time of normal system startup or shutdown, and runs in the context of the system start processing task or termination processing task (protection level 0). In some implementations, it may run as a quasi-task portion. In a system that supports dynamic loading of subsystems and device drivers, it may be called at other times besides system startup and shutdown.

When there are multiple subsystems and device drivers, entry routines are called one at a time for each at system startup and shutdown. In no case, are multiple entry routines called by different tasks at the same time. Accordingly, if subsystem or device driver initialization needs to be performed in a certain order, this order can be maintained by completing all necessary initializing processing before returning from an entry routine.

The entry routine function name is normally main, but any other name may be used if, for example, main cannot be used because of linking with the OS.

The methods of registering entry routines with the T-Kernel, specifying parameters, and specifying the order in which entry routines are called are all dependent on the T-Kernel implementation.

Startup Processing


INT ac  Number of parameters (≧ 0)
UB* av  Parameters (string)

Return Parameter

Return Codes Error Code


A value of ac ≧ 0 indicates startup processing. After performing the subsystem or device driver initialization, it registers the subsystem or device driver.

Passing of a negative value (error) as the return code means the startup processing failed. Depending on the T-Kernel implementation, the subsystem or device driver may be deleted from memory, so error must not be returned while the subsystem or device driver is in registered state. The registration must first be erased before returning an error. Allocated resources must also be released. They are not released automatically.

The parameters ac and av are the same as the parameters passed to the standard C language main() function, with ac indicating the number of parameters and av indicating a parameter string as an array of ac + 1 pointers. The last element of the array (av[ac]) is NULL.

av[0] is the name of the subsystem or device driver. Generally this is the file name of the subsystem or device driver, but what name is stored is implementation-dependent. It is also possible to have no name (blank string "").

Parameters at and after av[1] are defined for each subsystem and device driver.

After exit from the entry routine, the character string space specified by av is deleted, so parameters must be saved to a different location if necessary.

Termination Processing


INT ac  -1
UB* av  NULL

Return Parameter

Return Codes Error Code


A value of ac < 0 indicates termination processing. After deleting the subsystem or device driver registration, the entry routine releases allocated resources. If an error occurs during termination processing, the processing must not be aborted but must be completed as much as possible. If some of the processing could not be completed normally, error is passed in the return code.

The behavior if termination processing is called while requests to the subsystem or device driver are being processed is dependent on the subsystem or device driver implementation. Generally termination processing is called at system shutdown and requests are not issued during processing. For this reason, ordinarily behavior is not guaranteed in the case of requests issued during termination processing.