JPH09223027A - Message communication equipment - Google Patents

Abstract

PROBLEM TO BE SOLVED: To obtain a flexibility capable of providing suitable function in response to the dynamic request of user process or device driver, to the function of STREAMS fixed in accordance with system architecture. SOLUTION: A computer system 100 having a data path for communicating a message between a device and a user process is provided with a device driver 113 which is connected to a device 107 in order to perform the message communication with the device 107 and especially made suitable for identifying a message processing function for processing the message, and a stream head 111 which is arranged between the device driver 113 and the user process 103 in order to communicate the message with the user process and especially made suitable for providing a function controller 125 for controlling the execution of this message processing function identified by this device driver 113.

Description

Detailed Description of the Invention

[0001]

FIELD OF THE INVENTION The present invention relates to data communication, and more particularly, between a device and a host computer, between different processes executing on the same computer, and between multiple processes executing on different computers. The STREAMS framework that provides data communication for

[0002]

BACKGROUND OF THE INVENTION STREAMS, as well as various types of device drivers, have become the de facto industry standard framework for implementing data communication network protocols. STREAMS is a stream that provides a bidirectional data path between user-level processes, such as application programs, and device drivers in the kernel. Canonical streams include three main types of processing elements: stream heads, optional processing modules, and device drivers.

Device drivers are placed at the end or tail of the stream. The driver is added to the kernel by simply linking that object file to the kernel object file. However, according to the teachings of the prior art, the stream head is fixed because it has kernel-specific properties.

The stream head is ("user space")
Provides the interface between the user process level (known as
It contains a set of routines that execute only at the kernel process level (known as "kernel space").
Each of the prior art stream heads can only customize to a small range that can be selected from the limited processing options it supports. In the prior art, stream head processing routines are used for every stream in the system.

Access to the stream is STREAM
Provided via the open system call with the S file descriptor. For example, when a user process makes a system call, the stream head routine is invoked to perform data copying, message generation and control operations. The open system call builds the stream if the device driver is not already open. Once the stream has been constructed and the open has completed successfully, another open call to the same device will create a new file descriptor referencing the same stream.

The stream head is the only component in the stream that can copy data between the user process level and the kernel process level. All other components perform the data transfer by simply communicating messages, thus isolating them from direct interaction with the user process. Thus, open stream modules and drivers have no knowledge of user process level context or information as they execute only within the context of kernel process level. Such lack of context facilitates a "one size fits all" approach to handle communication between user processes and kernel components. Such an approach adapts the stream data interpretation, stream execution behavior, etc. of modules and drivers to satisfy the change requests of whatever user processes are currently executing on open devices. It imposes restrictions. For example, the modules and drivers in the prior art STREAMS are 32-bit kernels that execute on a 32-bit kernel and processor architecture.
From an application, a 64-bit kernel running on a 64-bit kernel and processor architecture
There are particular restrictions in terms of adaptation that support the transition to applications. When migrating to a 64-bit kernel, both the 32-bit user application and the 64-bit user application are 64-bit
STREA to support execution on the kernel
The MS has to be adapted. 64 open stream modules and drivers as in the example above
Because they only execute within the context of the bit kernel, and therefore lack the context knowledge of 32-bit applications, those modules and drivers are
It is constrained to adapt stream data interpretation, stream execution behavior, etc. to meet the requirements of 32-bit applications that differ from the requirements of bit applications.

Generally, whenever data is contacted, application and kernel processing performance is degraded.
Therefore, it is a good guideline that whenever data is accessed at the stream head, as many parallel mutually exclusive operations as possible should be performed at the stream head. , Reduces the need to re-contact the data downstream.

[0008]

Accordingly, what is needed is an apparatus and method that can control the performance of message processing at the stream head in response to the dynamic demands of a device or user process. That is, to identify message processing functions for kernel level stream processing modules or device drivers, and to adapt stream data interpretation, stream execution behavior, etc. according to various system requirements such as those of the device or user process. Functions are streams
What is needed is an apparatus and method for controlling the execution of those identified functions in a stream head so that it can be used in the head.

[0009]

SUMMARY OF THE INVENTION The present invention identifies a message processing function for a kernel level stream processing module or device driver to stream data according to various system requirements, such as the requirements of a device or user process. An apparatus and method for controlling the execution of those identified functions at a stream head so that the functions are available at the stream head for adapting interpretations, stream execution behaviors, and the like.

In general, the present invention includes a stream head specifically adapted to include a function controller that controls the execution of message processing functions identified by a device driver or stream processing module. Preferably, the device driver or stream processing module is a function that processes the messages of the stream, for example when the device driver is opened to build the stream or when the stream processing module is enabled on the stream. Is initially registered with the stream head. Alternatively, the driver or module passes one or more parameters to the stream head to invoke the function for each message.

In a particularly advantageous aspect, the present invention identifies a data format conversion function in the stream head to adapt stream data interpretation, stream execution behavior, etc., as required by a 32-bit user application. Provides a 64-bit kernel module or driver that controls the execution of functions. Similarly, the invention provides a module or driver that identifies the protocol conversion function and controls the execution of the function at the stream head to convert the message protocol format according to the protocol format requirements of the user application.

Moreover, by the module or driver identifying the function and by controlling the execution of the function in the stream head according to the invention, as many mutually exclusive operations as possible are performed by the function in parallel. Therefore, the need to contact the data downstream is reduced. For example, one of the most common requisite tasks for networking protocols is computing checksums to maintain data integrity when sending data packets. Prior art standard copy function copyin without checksum support
In contrast to (), the present invention identifies a kernel level module or driver specific function and controls its execution at the stream head to generate the required checksum in parallel. Enables functions to move data from user space to kernel space while in progress.

In addition, the present invention provides means and methods for providing a module or driver for identifying a function and controlling execution of the function at the stream head in response to dynamic changes in the state of the module or driver in the kernel. I will provide a. For example, the present invention prioritizes messages already queued as normal priority messages on the stream head in response to a change in module or driver priority state based on new information received from the connection network. Means and methods are provided for identifying a function that transforms a message to be processed.

[0014]

DETAILED DESCRIPTION OF THE INVENTION A block diagram of a preferred embodiment of the present invention is shown in FIG. Within the scope of computer system 100, which preferably includes one or more microprocessors controlled by appropriate software, a stream is between a user process 103 and a device 107, eg, a hardware device or pseudo device. Provides two-way communication of messages. The three main types of stream processing elements are:
A stream head 111, an optional processing module 112, and a hardware device, for example
A device driver 113, such as a driver or pseudo device driver. In a preferred embodiment, the present invention allows STREAMS to register message processing functions at the stream head.
Extend the framework. STR related to the present invention
For details on EAMS, see UNIX System V Network Programmin.
g by S. Rago, Addison Wesley professional computing
It is described in Chapter 3 and Chapters 9 to 11 of the series (1993).

As shown in FIG. 1, the device driver 11 is connected to the device for communicating messages to and from the device. Modules and drivers perform data transfer only by communicating messages, and thus are isolated from any direct interaction with a user process, such as a user application program. The stream head is located between the device driver and the user process for message communication with the user process. STRE
Within the scope of the AMS framework, among the above three types of processing elements, the stream head is the user process level and the kernel process
It is the only processing element that can copy data between levels. Although the details will be described later, the present invention is
It comprises a kernel-level module or driver that identifies one or more message processing functions 121.
Preferably, each message processing function is identified by at least one function pointer shown in FIG.
The stream head includes a controller 125 that controls the execution at the stream head of the identified message processing function.

In a preferred embodiment of the invention, when the device driver builds the stream, or
When a stream processing module is enabled on a stream, the driver or module passes the function pointer to the controller at the stream head to register the message processing function at the stream head. Thus, in the preferred embodiment, the stream head includes a register block or one register 127 to record the identity of the message processing function by recording the function pointer therein. Alternatively, the driver or module passes one or more parameters for each message to the stream head to invoke the message processing function. Therefore, functions are made available at the stream head so that stream data interpretation, stream execution behavior, etc. can be adapted according to system requirements such as those of device 107 or user process 103.

Preferably, the stream head register block and controller use suitable software including public data structures that record function pointers corresponding to functions registered by the module or driver. It is realized within the range of. The public data structure holds a function pointer that corresponds to the function registered by the module or driver. The function vector reflects the current function registration status. Therefore, the stream head instruction <str
The following public data structures are defined within eam.h>.

[0018]

[Table 1] struct sth_func_reg {int (* sth_copyin) (); / * Writing side copyin * / int sth_copyin_threshold; / * Parameter passed to sth_copyin () * / int (* sth_32_to_64) (); / * Writing side 32-to-64-bit conversion function * / int (* sth_write_opt) (); / * Write side option function * / int (* sth_read_opt) (); / * Read side option function * / int (* sth_ioctl_opt) () ; / * ioctl option function * / int (* sth_64_to_32) (); / * reader 64-bit conversion function * /}

Within the scope of the stream head declaration (ie private structure), the following structures are defined.

[0020]

[Table 2] struct sth_s {... struct sth_func_reg_sth_f_reg; ...}

FIG. 2 illustrates the operational flow of the preferred embodiment of the present invention. In the preferred embodiment, the stream module or driver is str_func_ins
Register the function via tall (). Whenever a module or driver is installed, or whenever a module or driver decides to register a function, str_func_ins
tall () is called. For example, driver A identifies the 32 to 64 bit and 64 bit to 32 bit conversion functions for the application to use on the write or read path. These functions are registered when the driver is opened. This allows a single driver instance to support 32-bit and 64-bit applications simultaneously. Similarly, module enable (enabled)
If an action occurs, STREAMS invokes the module's open routine to perform stream head registration.

As shown in FIG. 2, the module uses the function pointer to identify the sth_32_to_64 function and forwards the function pointer to the stream head controller for recording. The module may also disable the function by sending a message. For example,
The module disables the function by sending a message, which results in no (null) evaluation of the record in the data structure as expressed by sth-> sth_func_reg.sth_32_to_64 = NULL.

Two STREAMS components are
If you register conflicting message handling functions, such as two sth_read_opt () functions, the stream head structure will reflect the highest component function within the stack. If there is no conflict, the stream head will reflect the functional capabilities of both components. The preferred calling sequence is as follows:

[0024]

[Table 3] str_func_install (struct sth_func_reg * func_
reg, int func_mask); func_mask is a bit mask composed of any of the following.

[0025]

[Table 4] / * flags for the func-mask * / #define FUNC_REG_COPYIN_ENABLE 0X0001 #define FUNC_REG_COPYIN_DISABLE 0X0002 #define FUNC_REG_32_TO_64_ENABLE 0X0004 #define FUNC_REG_32_TO_64_DISABLE 0X0008 #define FUNC_REG_WRITE_OPT_ENABLE 0X0010 #define FUNC_REG_WRITE_OPT_DISABLE 0X0020 #define FUNC_REG_READ_OPT_ENABLE 0X0040 #define FUNC_REG_READ_OPT_DISABLE 0X0080 #define FUNC_REG_64_TO_32_ENABLE 0X0100 #define FUNC_REG_64_TO_32_DISABLE 0X0200 #define FUNC_REG_IOCTL_OPT_ENABLE 0X0400 #define FUNC_REG_IOCTL_OPT_DISABLE 0X0800

This calling sequence specifies which functions are automatically registered at open or at module startup. func_reg and func_mask are stored in the module switch table entry as follows:

[0027]

[Table 5] struct modsw {struct modsw * d_next; struct modsw * d_prev; char d_namee [FMNAMESZ + 1]; char d_flags; SQHP d_sqh; int d_curstr; struct streamtab * d_str; struct streamtab * d_default_alt; int d_naltstr; struct streamtab * d_altstr; int d_sq_level; int d_refcnt; int d_major; struct sth_s * d_pmux_top; int d_func_mask; struct sth_func_reg * d_func_reg;};

The module or driver is M_SETOPTS
Starts or stops the registered message handling functions by notifying the stream head through a message. This is stroptio defined in <stream.h>
This is done by extending the ns data structure.

[0029]

[Table 6] struct stroptions {ulong so_flags; / * Option to be set * / short so_readopt; / * Read option * / ushort so_wroff; / * Write offset * / long so_minpsz; / * Minimum read packet size * / long so_maxpsz; / * Maximum read packet size * / ulong so_hiwat; / * Read queue high mark * / ulong so_lowat; / * Read queue low mark * / unsigned char so_band; / * Upper and lower mark width * /

By extending this data structure as follows, the original layout is maintained so that modules or drivers that do not support function registration continue to operate as before.

[0031]

[Table 7] struct stroptions {ulong so_flags; / * Option to be set * / short so_readopt; / * Read option * / ushort so_wroff; / * Write offset * / longso_minpsz; / * Minimum read packet size * / longso_maxpsz; / * Maximum read packet size * / ulong so_hiwat; / * Read queue high mark * / ulong so_lowat; / * Read queue low mark * / unsigned char so_band; / * Upper and lower mark width * / short so_device_id; / * Driver or module identifier * / short so_func_mask; / * enabled functions * /};

The so-device-id is the device identifier returned when the driver or module is installed in the system. For the preferred embodiment, this is str_instal
It is executed via l (). str_install () creates a unique so_device_id that the driver or module records in a global variable that is available whenever it wants to perform a function registration. so_func_mask specifies which function should be activated or deactivated. If the bit is not defined, the corresponding registered message handling function remains valid.

Modules or drivers are capable of sending specially adapted M_SETOPTS messages at any time they choose to modify stream head characteristics. When this structure is deciphered,
The code for the stream head checks so_func_mask and based on the flags set, the corresponding stream
Record or invalidate head function address.
If the function is enabled or remains enabled, the stream head sets a flag to indicate that the function registration should be checked during stream head message processing. .

To use the present invention in conjunction with system calls, the following adaptations are made. Regarding the write () system call, the following code is STREAMS
Added to the embodiment. Registered write functions preferably include protocol dependent checksum offload functions that combine the movement of data from user space to kernel space with automatic checksum calculations. By using this technique, the present invention continues to remain protocol independent while adding value to the STREAMS framework.

Preferably, such a copyin / checksum combining function must reference a threshold variable to improve processing performance. This threshold variable is stored as part of the original data structure and passed to the function. Then the function looks up the length field of uniop, compares it with the threshold variable, and registers
Determine if it is appropriate to execute the copyin function. The environment that does not perform the above operation is protocol dependent type,
This may be the case when the basic protocol allows only small packets, such as 512 bytes long, to be sent out, and the application sends out 8 Kbytes of data. In such cases, 16
The performance is better using standard copy and checksum processing rather than invoking a single registered copy / checksum combination function call and other related overhead. Determining the appropriate formula for when to launch etc will require some experimentation for each protocol, which is independent of the STREAMS framework and embodiments of the invention. . The following opcode examples relate to the operation of the invention in conjunction with the write () system call.

[0036]

[Table 8] / * If the function is registered, the controller executes the appropriate function * / if (sth-> sth_flags & F_STH_FUNC_REG_ENABLED) {if (sth-> sth_f_reg.sth_copyin) {error = (* sth -> sth_f_reg.sth_copyin) (mp, w_cnt, uiop, sth-> sth_copyin_threshold); / * If EAGAIN, copyin was not executed, so the normal task is executed * / if (error == EAGAIN) UIOMOVE_WRITE ( mp, cnt, uiop, error); if (error) goto error_processing_code)} else {UIOMOVE_WRITE (mp, cnt, uiop, error);} / * The controller is a 32-bit application and is * and defined If so, the conversion from 32 to 64 bits is performed. * This is run on mblk. * / if (sth-> sth_f_reg.sth_32_to_64 && uarea-> 32bit_hint) error = (* sth-> sth_f_reg.sth_32_to_64) (mp); / * Indicates that other types of option processing are performed on the output direction data * Run this on mblk if the driver / module wants it. * / if (sth-> sth_f_reg.sth_write_opt) error = (* sth-> sth_f_reg.sth_write_opt) (mp);} else {/ * The function is not defined, so the original code is executed. * /}

The rest of the write path code executes normally. STREA regarding putmsg () / putpmsg ()
The MS framework is extended as follows. putm
sg () / putpmsg () allows the caller to specify the control data passed to the lower module or driver using the M_PROTO or M_PCPROTO message. This data may require conversion or post-processing once it is brought into the kernel. An example of such a case is the TPI (ie Transport Provi
der Interface (Transport Provider Interface) is a 32-bit application compiled using a 32-bit version. This interface defines a structure containing data elements that are correctly decoded by the present invention as either 32 or 64 bits. These data elements are 64
In order for the bit system to correctly interpret the data,
It needs to be converted to a 64-bit data element. Additionally, once it is brought into the kernel, the control data may need some other form of transformation (note: it is brought in via an alternate copyin path, such as on the write () path). The normal data that is submitted does not have to change). An example of a suitable instruction code is as follows.

[0038]

[Table 9] / * If it is in process, the control part is first copied to the kernel. * The normal copy in operation is performed, then the post processing is performed as follows. * / if (error = COPYIN (user_ptr, mp, cnt, ctl)) {/ * Perform error recovery processing * /} if (sth-> sth_flags & F_STH_FUNC_REG_ENABLED) {if (sth-> sth_f_reg.sth_copyin) {error = (* sth-> sth_f_reg.sth_copyin) (mp, w_cnt, uiop, sth-> sth_copyin_threshold); / * If EAGAIN, copyin was not executed, so the normal task is executed. * / if (error == EAGAIN) error = COPYIN (user_ptr, mp, cnt, ctl); if (error) goto error_processing_code;} else {COPYIN (user_ptr, mp, cnt, ctl);} / * Caller is 32 Performs 32 to 64 bit conversion if it is a bit application and * and is defined. * / if (sth-> sth_f_reg.sth_32_to_64 && uarea-> 32bit_hint) error = (* sth-> sth_f_reg.sth_32_to_64) (mp); / * Indicates that other types of option processing are performed on the output direction data * Run this on mblk if the driver / module wants it. * / if (sth-> sth_f_reg.sth_write_opt) error = (* sth-> sth_f_reg.sth_write_opt) (mp);} else {/ * The function is not defined, so the original code is executed. * /

With respect to the read () system call, the code is essentially similar, but the functionality functionality is replaced with the functionality functionality that requires module / driver modification. The present invention comprises a 64-bit kernel module or driver that handles functions adapted to stream data interpretation, stream execution behavior, etc. according to the requirements of a 32-bit user process. In particular, this function examines the thread of the user process to determine if it needs the 32-bit format or the 64-bit format. If the user process requires a 32-bit format, the function returns a 32-bit data format required by the user process and a 64-bit data format required by the device driver.
Convert the message data format between data formats.
Similarly, the current-used version of the protocol initially accepted at the time of connection (for example, Internet Protocol (IP) version 4
If the application cannot interact with the protocol (IP) version 6, the data is then converted into the correct protocol format. The following is an example of the code for this function.

[0040]

[Table 10] / * If the function is already registered, the controller executes the appropriate function. * / if (sth-> sth_flags & F_STH_FUNC_REG_ENABLED) {/ * If the driver / module wants any other form of optional processing * to be performed on the outbound data, do this on mblk. * It is an example of this case that the conversion from IPv4 to IPv6 is performed. * / if (sth-> sth_f_reg.sth_read_opt) rror = (* sth-> sth_f_reg.sth_read_opt) (mp);} / * If the calling application is a 32-bit application and the * transformation is registered, then Invoke the function * before moving the data to user space. t application and there is a * / if (sth-> sth_f_reg.sth_64_to_32 && uarea-> 32bit_hint) error = (* sth-> sth_f_reg.sth_64_to_32) (mp);} / * To move data * / UIOMOVE_READ (mp, cnt, uiop, error);

The use of the invention in connection with the getmsg () and getpmsg () system calls is similar to that of the read () system call above, but with additional code to handle the control data portion of the message. included. An example of the code is as follows.

[0042]

[Table 11] / * If the function is already registered, the controller executes the appropriate function. * / if (sth-> sth_flags & F_STH_FUNC_REG_ENABLED) {/ * If the driver / module wants some other form of * optional processing to be done on outbound data, do this on mblk. * It is an example of this case that the conversion from IPv4 to IPv6 is performed. * / if (sth-> sth_f_reg.sth_read_opt) error = (* sth-> sth_f_reg.sth_read_opt) (mp); / * Next, perform 32-bit conversion for the M_DAYTA part of the message, * if that function exists. If it is registered, execute it. * / if (sth-> sth_f_reg.sth_64_to_32 && uarea-> 32bit_hint) error = (* sth-> sth_f_reg.sth_64_to_32) (mp);} error = COPYOUT (mp, user_ptr, cnt, ctl);

When the registered function processing is completed, the data is moved to the user space using the normal execution path.

With respect to the ioctl path, similar steps are performed depending on whether data is being moved to or from the kernel. It is assumed in practice that the optional ioct function performs the data movement, or limits the data movement to simplify the role of the pre- or post-processing described above. It should be appreciated that ioctls can also communicate with different modules or drivers. Therefore, if this optional structure is used, have an understanding of how these messages are interpreted (under the understanding that the highest module / driver is usually the final arbiter). , Modules and drivers are built. Although this ioctl path is defined for completeness purposes, it is recommended that ioctl use per-message functions. This is because each module or driver that handles ioctls can target a particular message. An example of the code is as follows.

[0045]

[Table 12] if (sth-> sth_flags & F_STH_FUNC_REG_ENAB
LED &&sth-> sth_f_reg.sth_ioctl_opt) error = (* sth-> sth_f_reg.sth_ioctl_opt) (mp, direct
ion_hint);

The present invention further comprises a module or driver that identifies a function and provides means for controlling execution at the stream head in response to dynamic changes in the state of the module or driver in the kernel. For example, the present invention typically prioritizes the processing of messages already held in the queue on the stream head in response to a change in module or driver priority state based on new information received from the connection network. It provides a means to identify the function to convert to priority. This eliminates the need to modify the user application or interface library to provide the required functionality.

In an alternative embodiment of the invention, the STRE
The AMS framework uses read, g for M_COPYOUT
It is extended to support the ability of a module or driver to perform function registration per message on the ingress path, such as etmsg, getpmsg, ioctl. The reason such functionality is provided is that the module or driver need not always have one function set invoked for every message going upstream, but only for a packet with a number N. This is because there are cases where it does not exist. Such functionality is added to make the system flexible. The underlying concept of providing such a function is still the same. Such a function is invoked to transform the data based on the launched application. The most common use is for the 64-bit to 32-bit conversion, which is always given as an example for the parameters of the invention. First, the message structure used to describe the user data is modified appropriately. This data structure is defined in <stream.h>.

[0048]

[Table 13] struct msgb {struct msgb * b-next; / * Next message on the queue * / struct msgb * b_prev; / * Previous message on the queue * / struct msgb * b-cont; / * Next message block * / unsigned char * b-rptr; / * First unread data byte * / unsigned char * b-wptr; / * Rewrite unwritten data byte * / struct datab * b-datap; / * Data block * / unsigned char b-band; / * message priority * / unsigned char b-pad1; unsigned short b_flag; / * message flag * / (int32 *) b_func; / * function to be invoked * / MSG_KERNEL_FIELDS};

In addition, a new flag is defined in the msgb-> b_flag field. This new flag is
Used to indicate that the function stored in the msgb structure must be invoked for user data when the data is moved from the kernel to user space via the next application system call. It

[0050]

[Table 14] #define MSGFUNCREG 0x2000 / * Execute the function embedded in the data. * /

In an alternative embodiment, the b_flag field is set, but a flag is used that indicates which registration message processing function should be invoked. This is also a driver /
The module has dev in the new msgb field b_device_id
Requires inclusion of the ice_id value.

[0052]

[Table 15] #define MSGREADOPT 0x6000 #define MSGIOCTLOPT 0xaOOO #define MSG64TO32 OxbOOO

The above code is modified as follows. re
For the ad, getmsg, getpmsg, and ioctl paths, the code contains the following two lines executed by the controller.

[0054]

[Table 16] / * Checks whether the processing for each message is enabled. * / if (mp-> b_flag & MSGFUNCREG) error = (* mp-> b_func) (mp, uarea-> 32bithint); / * If the function is registered, execute the appropriate function. * / if (sth-> sth_flags & F_STH_FUNC_REG_ENABLED) {...}

An alternative embodiment is as follows.

[0056]

[Table 17] / * Check whether the processing for each message is enabled. * / if (mp-> b_flag & MSGFUNCREG) {error = (* (find_func (b_device_id, b_flag)) (mp, uarea-> 32bithint); / * If the function is registered, execute the appropriate function. * / if (sth-> sth_flags & F_STH_FUNC_REG_ENABLED) {...}

Various structures and codings can be used for these register functions. The following is an example of a simple structure.

[0058]

[Table 18] int32 drv_a_32_to_64 (MBLKP mp) {/ * Check the message type to determine the conversion code to be executed. * There will be one set of conversion codes for each message type. * It would be best for each driver or module to create an ABI (Application Binary Interface) to * communicate information between the application and itself. By doing so, you can do the per-message conversion without writing the tedious * code to understand all message types. * If the calling application instance is a 32-bit compiled * application, this conversion code is reused * to reverse the conversion * on the path from input direction 64 to 32 bits. For other types of option processing or copy / checksum *, similar code may exist * because data movement / manipulation is per message. For example, you don't usually need * copy checksums for ioctl paths. Alternatively, a copyin / modify utility may be required to perform * automatic conversion of data during data movement between the user and the kernel without having to * execute the given execution path. * / switch (mp-> b_datap-> db_type) {case M_DATA: / * Perform conversion based on pre-defined driver ABI * / break; case M_PROTO: / * Convert based on pre-defined driver ABI Execute * / break; case M_PCPROTO: / * Execute conversion based on pre-defined driver ABI * / break; case M_IOCTL: / * Execute conversion based on pre-defined driver ABI * / break; case M_COPYIN: / * Perform conversion based on predefined driver ABI * / break; case M_COPYOUT: / * Perform conversion based on predefined driver ABI * / break; default: / * Do nothing * /} }

As described above, the present invention provides an apparatus and method for controlling the execution of a message processing function at the stream head, comprising a kernel level module or driver that identifies the message processing function. While particular embodiments of the invention have been described above,
The invention should not be limited to the particular forms or configurations of such embodiments, and various modifications and changes can be made to the above embodiments without departing from the scope and spirit of the invention.

The present invention includes the following embodiments as examples. (1) In a computer system having a data path for communicating a message between a device and a user process, identifying a message processing function connected to the device for communicating a message with the device and processing the message. A device driver specially adapted to perform message processing functions identified by the device driver connected between the device driver and the user process for communicating messages with the user process. A stream head specially adapted to include a function controller for controlling the. (2) The device driver comprises a function pointer identifying the message processing function and is adapted to transfer the function pointer to the function controller of the stream head, the function controller receiving the function pointer. The apparatus according to (1) above, which is adapted to: (3) The apparatus according to (1) above, wherein the stream head includes a register for recording an identification of the message processing function. (4) The device according to (1), wherein the message processing function includes a function that converts a data format of a message. (5) The apparatus according to (1) above, wherein the message processing function includes a function for checking a thread of the user process to determine a data format of a message generated by the user process.

(6) The message processing function converts the data format of the message between the 32-bit data format required by the user process and the 64-bit data format required by the device driver. The apparatus according to (1) above, which includes a function to perform. (7) The device according to (1), wherein the message processing function includes a function for converting a protocol format of a message. (8) The message processing function includes a function that generates a checksum for each of the messages.
An apparatus according to claim 1. (9) The stream head includes a queue to hold messages, and the message processing function modifies the messages held on the stream head queue to check the status of the device driver. The device according to (1) above, comprising a function responsive to dynamic changes. (10) The stream head includes a queue for holding messages, and the message processing function modifies the priority of messages held on the queue of the stream head. The apparatus according to (1) above, including a function that responds to dynamic changes in the priority state of the device driver. (11) In a computer system, a stream processing module specially adapted for identifying a message processing function, and a stream processing module connected between the stream processing module and the user process for communicating a message with the user process. A stream head specially adapted to include a function controller controlling execution of the message processing function identified by the module.

(12) A method of communicating a message between a device and a user process in a computer system, the message communication between the device and the device driver, the device driver and the stream head. Communication of messages between them, identification of message processing functions, registration of said message processing functions at said stream head, execution of said message processing functions, and between said stream head and said user process. A message communication method including: (13) identifying the message processing function includes using a device driver to identify the message processing function,
The message communication method according to (12) above. (14) In (12) above, message communication between the device driver and the stream head is executed via a processing module, and identification of the message processing function is executed using the processing module. Message communication method described. (15) The message communication method according to (12), wherein the execution of the message processing function includes data format conversion of a message. (16) The message communication method according to (12), wherein the execution of the message processing function includes checking a thread of the user process for determining a data format of a message generated by the user process. (17) Execution of the message processing function requires a 32-bit data format required by the user process and 64 required by the device driver.
The message communication method according to (12) above, which includes data format conversion of a message between bit data formats. (18) The message communication method according to (12), wherein the execution of the message processing function includes protocol format conversion of a message. (19) Execution of the message processing function includes checksum generation for each of the messages.
The message communication method described in. (20) Including the holding of a message in the stream head queue, and executing the message processing function changes the state of the device driver by modifying the message held in the stream head queue. The message communication method according to (12) above, which includes a response to a dynamic change.

[0063]

According to the present invention, the system functions of STREAMS, which are conventionally fixed according to the system architecture in which STREAMS is implemented, perform appropriate functions in response to a dynamic request of a user process or a device driver. The effect of providing flexibility that can be provided is exhibited. This allows, for example, a 32-bit application running on a 64-bit kernel and processor architecture to run on a 64-bit kernel and processor architecture without making application changes. It will be possible to run on.

[Brief description of drawings]

FIG. 1 is a block diagram showing one of the preferred embodiments of the present invention.

FIG. 2 is a diagram showing an operational flow of a preferred embodiment of the present invention.

[Explanation of symbols]

 100 Computer System 103 User Process 107 Device 111 Stream Head 112 Module 113 Device Driver 121 Message Processing Function 125 Controller 127 Register

Claims (1)

[Claims] 1. A computer system having a data path for communicating a message between a device and a user process, comprising a message processing function connected to the device for communicating a message with the device and processing the message. A device driver specially adapted to identify, said message handling function connected between said device driver and said user process for communicating messages with said user process and identified by said device driver A stream head specially adapted to include a function controller for controlling execution of the stream.