JP4232678B2 - Information processing apparatus, information processing method, program, and program recording medium - Google Patents

Description

  The present invention relates to an information processing apparatus, an information processing method, a program, and a program recording medium, and in particular, information that enables, for example, AV (Audio Visual) data or the like to be recorded and reproduced on a recording medium in real time. The present invention relates to a processing device, an information processing method, a program, and a program recording medium.

  In recent years, for example, it has been required to record and reproduce high bit rate AV data on an optical disc.

  Therefore, for example, a disk drive for recording a plurality of data series such as video data and accompanying audio data on an optical disk periodically and so that the boundary coincides with the boundary of an optical disk sector or the like. The present applicant has previously proposed (for example, see Patent Document 1).

  According to this disk drive, video data and audio data are collected to some extent and recorded in a continuous recording area on the optical disk, and the collected data can be read and written without seeking.

  Furthermore, since the boundary between the video data and the audio data matches the boundary between the sectors of the optical disk, the video data and the audio data are not mixed in one sector. For this reason, for example, only video data or only audio data can be read. That is, for example, when only video data is required, only video data can be read from the optical disc, and only video data can be read compared to the case where video data and audio data are mixed in one sector. Data can be read efficiently (at high speed). The same applies to audio data.

JP 2004-005895 A.

  The applicant further reserves a free area closest to the recording area in which data was recorded immediately before, for example, among consecutive free areas of a predetermined size or more on the recording area of the optical disc, and the free space is reserved. A disk drive that records data in the area is also proposed.

  In this case, ideally, a series of data is recorded in a continuous recording area on the optical disk. Therefore, it is possible to suppress the occurrence of seek during data recording / playback, and record high bit rate AV data on the optical disc in real time, and play back high bit rate AV data from the optical disc in real time. Can do.

  Here, among the continuous free areas of a predetermined size or more on the recording area of the optical disc, a free area closest to the recording area in which data was recorded immediately before is reserved and data is recorded. Thus, a disk drive that suppresses the occurrence of seeks during data recording / reproduction will be referred to as a professional disk drive as appropriate.

  Further, an optical disc on which data is recorded by a professional disc drive is hereinafter referred to as a professional disc as appropriate. Further, the professional disc is hereinafter abbreviated as PD (Professional Disc) as appropriate.

  By the way, recently, high-performance and low-cost computers have been realized along with the price reduction of high-speed CPUs (Central Processing Units) and large-capacity memories. Further, in such a computer, an application (program) (hereinafter referred to as “AV application” as appropriate) that performs editing and other processing of large-capacity AV data is also realized.

  Then, there is a request for the computer to connect the PD drive, for example, in an internal form or externally, and access the PD drive from an AV application to read / write AV data to / from the PD. It is increasing.

  However, in this case, it may not be guaranteed that AV data is read from and written to the PD in real time.

  That is, in recent computers, generally, a plurality of applications can be executed simultaneously by multitasking. However, even if multiple applications are executed simultaneously, the processing corresponding to each of the multiple applications is performed in a time-sharing manner. For example, before the AV application accesses the PD, other applications When accessing the PD, when the AV application accesses the PD, an unscheduled seek occurs in the PD drive.

  If another application is accessing the PD when the AV application tries to access the PD, the AV application will wait for access to the PD.

  As described above, when an unscheduled seek occurs in the PD drive or access to the PD by the AV application is awaited, it becomes difficult to read and write AV data to and from the PD in real time.

  The present invention has been made in view of such circumstances, and enables data to be recorded or reproduced on a recording medium such as an optical disc in real time.

The information processing apparatus of the present invention sets permission information indicating permission or non-permission of processing of a packet having processing information requested to the device driver corresponding to an access request to the recording medium , and sets the permission information to the set permission information Therefore, a process of the packet that corresponds to an access request from a particular application, the pause state is a state to stop processing the packet that corresponds to an access request from another application or access from all applications the run state is a state for processing the packet that corresponds to the request, the state setting means for setting as the current status, the packets corresponding to the access request from the application, and queue control means for storing in the queue, the current If the state is the pause state, among the packets stored in the queue Performs processing of a packet that corresponds to an access request from specific application, if the current state is the run state, and characterized in that it comprises an access request processing means for processing all the packets stored in the queue To do.

The state setting means can set the pause state or the run state as the current state in accordance with a user operation .

The information processing apparatus may further include a cache function setting means for setting whether or not the cache function is used, and the access request processing means further includes a result of setting whether or not the cache function is used by the cache function setting means. Therefore, it is possible to perform the processing of the packet corresponding to the access request.

The access request processing unit, only the processing of the packet corresponding to an access request from a particular application, can be performed in accordance with the setting result of the presence or absence of use of the cache function.

The information processing apparatus can be a filter driver that filters a packet corresponding to an access request and passes the packet to a file system driver.

  The data read / written to / from the recording medium can include at least AV (Audio Visual) data.

  In the recording medium, a free area closest to the recording area in which data was recorded immediately before is reserved among continuous free areas of a predetermined size or more on the recording area, and data is recorded. be able to.

The information processing method of the present invention sets permission information indicating permission or non-permission of processing of a packet having processing information requested to the device driver corresponding to an access request to the recording medium, and sets the permission information in the set permission information. Therefore, a process of the packet that corresponds to an access request from a particular application, the pause state is a state to stop processing the packet that corresponds to an access request from another application or access from all applications the run state is a state for processing the packet that corresponds to the request, the state setting step of setting as the current status, the packets corresponding to the access request from the application, and queues control step of storing in the queue, the current If the state is the pause state, packets stored in the queue Performs processing of a packet that corresponds to an access request from a particular application of out, if the current state is the run state, to include the access request processing step of performing processing for all the packets stored in the queue Features.

The program of the present invention sets permission information indicating permission or non-permission of processing of a packet having processing information requested to the device driver corresponding to an access request to the recording medium, and according to the set permission information, performs processing of a packet that corresponds to an access request from a particular application, the pause state is a state to stop processing the packet that corresponds to an access request from another application, or to an access request from all applications the run state is a state for processing the packet that corresponds, and state setting step of setting as the current status, the packets corresponding to the access request from the application, and queues control step of storing in the queue, the current state If a pause condition, the packet stored in the queue Chino performs processing of a packet that corresponds to an access request from a specific application, if the current state is the run state, characterized in that it comprises an access request processing step of performing processing for all the packets stored in the queue And

The program recorded on the program recording medium of the present invention sets permission information indicating permission or disapproval of processing of a packet having processing information requested to the device driver corresponding to an access request to the recording medium. according permission information set, performs the processing of the packet that corresponds to an access request from a specific application, other pause state is a state to stop processing the packet that corresponds to an access request from the application or, queue the run state process is a state that performs the packet that corresponds to an access request from all applications, and state setting step of setting as the current status, the packets corresponding to the access request from the application, and stores in a queue Control step and current state is paused Performing case, a process of the packet that corresponds to an access request from a particular application of the packets stored in the queue, if the current state is the run state, the processing of all the packets stored in the queue And an access request processing step.

In the present invention, permission information indicating permission or non-permission of processing of a packet having processing information requested to the device driver corresponding to an access request to the recording medium is set, and specified according to the set permission information. performs processing of packets corresponds to the access request from the application of the pause state is a state to stop processing the packet that corresponds to the access request from another application, or, pair access request from all applications The run state in which the corresponding packet is processed is set as the current state. The packets corresponding to the access request from the application is stored in the queue, the current state be a pause state, the packet that corresponds to an access request from a particular application of the packets stored in the queue If processing is performed and the current state is the run state, all the packets stored in the queue are processed.

  According to the present invention, only an access request from a specific application can be permitted. As a result, for example, data can be recorded or reproduced in real time.

  Embodiments of the present invention will be described below. Correspondences between constituent elements described in the claims and specific examples in the embodiments of the present invention are exemplified as follows. This description is to confirm that specific examples supporting the invention described in the claims are described in the embodiments of the invention. Therefore, even if there are specific examples that are described in the embodiment of the invention but are not described here as corresponding to the configuration requirements, the specific examples are not included in the configuration. It does not mean that it does not correspond to a requirement. On the contrary, even if a specific example is described here as corresponding to a configuration requirement, this means that the specific example does not correspond to a configuration requirement other than the configuration requirement. not.

  Further, this description does not mean that all the inventions corresponding to the specific examples described in the embodiments of the invention are described in the claims. In other words, this description is an invention corresponding to the specific example described in the embodiment of the invention, and the existence of an invention not described in the claims of this application, that is, in the future, a divisional application will be made. Nor does it deny the existence of an invention added by amendment.

An information processing apparatus according to claim 1 is provided.
In an information processing apparatus (for example, PD filter 53 in FIG. 4) that processes an access request that is a request for access to a recording medium from an application,
Set permission information indicating permission or non-permission of processing of a packet having processing information requested to a device driver corresponding to the access request to the recording medium, and specify a specific application in accordance with the permission information set. said access the corresponding to the request performs a process of the packet, pause state is a state to stop processing the packet that corresponds to the access request from another application, or the access from all the applications from the run state is a state in which the processing of the packet that corresponds to the request, the state setting means for setting as the current state (e.g., such as the filter core 53A in FIG. 6 which performs the processing of step S157 and S159 of FIG. 15) and ,
Queue control means for storing the packet corresponding to the access request from the application in a queue (for example, the filter core 53A in FIG. 6 that performs the process of step S165 in FIG. 15);
If the current state is the pause state, performs processing of the packet to the correspond to the access request from a specific application of said packet stored in the queue, the current state said run And an access request processing means for processing all the packets stored in the queue (for example, the filter core 53A in FIG. 6 that performs the processing in steps S173 and S175 in FIG. 16). And

An information processing apparatus according to claim 3 is provided.
A cache function setting means for setting whether or not the cache function is used (for example, the filter core 53A in FIG. 19 that performs the processing in steps S304 and S305 in FIG. 23);
It said access request processing means further in accordance with the cache function setting means by use whether setting result of caching, and performs processing of the packet corresponding to the access request.

The information processing apparatus according to claim 5 is:
A filter driver that filters the packet corresponding to the access request and passes the packet to a file system driver (for example, the PD filter 53 in FIG. 4).

The information processing method according to claim 8 comprises:
In an information processing method for processing an access request that is a request for access to a recording medium from an application,
Set permission information indicating permission or non-permission of processing of a packet having processing information requested to a device driver corresponding to the access request to the recording medium, and specify a specific application in accordance with the permission information set. said access the corresponding to the request performs a process of the packet, pause state is a state to stop processing the packet that corresponds to the access request from another application, or the access from all the applications from the run state is a state in which the processing of the packet that corresponds to the request, the state setting step of setting as the current state (for example, step S157 and S159 of FIG. 15),
A queue control step (for example, step S165 in FIG. 15) for storing the packet corresponding to the access request from the application in a queue;
If the current state is the pause state, performs processing of the packet to the correspond to the access request from a specific application of said packet stored in the queue, the current state said run If it is in a state, it includes an access request processing step (for example, steps S173 and S175 in FIG. 16) for processing all the packets stored in the queue.

The program according to claim 9 and the program recorded on the program recording medium according to claim 10 are:
In a program that causes a computer to process an access request, which is a request for access to a recording medium from an application,
Set permission information indicating permission or non-permission of processing of a packet having processing information requested to a device driver corresponding to the access request to the recording medium, and specify a specific application in accordance with the permission information set. said access the corresponding to the request performs a process of the packet, pause state is a state to stop processing the packet that corresponds to the access request from another application, or the access from all the applications from the run state is a state in which the processing of the packet that corresponds to the request, the state setting step of setting as the current state (for example, step S157 and S159 of FIG. 15),
A queue control step (for example, step S165 in FIG. 15) for storing the packet corresponding to the access request from the application in a queue;
If the current state is the pause state, performs processing of the packet to the correspond to the access request from a specific application of said packet stored in the queue, the current state said run If it is in a state, it includes an access request processing step (for example, steps S173 and S175 in FIG. 16) for processing all the packets stored in the queue.

  Embodiments of the present invention will be described below with reference to the drawings.

  FIG. 1 shows a configuration example of an embodiment of an information processing system to which the present invention is applied.

  In FIG. 1, the information processing system includes a PC (Personal Computer) 1 and a drive 2.

  The PC 1 stores an OS (Operating System) and applications (programs), and performs various processes by executing the applications under the control of the OS.

  The drive 2 is, for example, the PD (Professional Disc) drive described above, and is connected to the PC 1 via the 1394 cable 4. The drive 2 can be attached to and detached from the optical disk 3 that is a PD, and communicates with the PC 1 in accordance with the IEEE (Institute of Electronic and Electronics Engineers) 1394 standard. Read and write AV data and other data.

  The drive 2 does not need to be a PD drive, and the optical disc does not need to be a PD. In addition, communication conforming to a standard other than IEEE1394 can be performed between the PC 1 and the drive 2.

  Next, FIG. 2 shows a hardware configuration example of the PC 1 of FIG.

  The PC 1 includes a CPU (Central Processing Unit) 12. An input / output interface 20 is connected to the CPU 12 via the bus 11, and the CPU 12 operates the input unit 17 including a keyboard, a mouse, a microphone, and the like by the user via the input / output interface 20. When a command is input by the equalization, a program stored in a ROM (Read Only Memory) 13 is executed accordingly. Alternatively, the CPU 12 may be a program stored in the hard disk 15, a program transferred from a satellite or a network, received by the communication unit 18 and installed in the hard disk 15, or a removable recording medium 21 installed in the drive 19. The program read and installed in the hard disk 15 is loaded into a RAM (Random Access Memory) 14 and executed. As a result, the CPU 12 performs processing according to a flowchart described later or processing performed according to the configuration of a block diagram described later. Then, the CPU 12 outputs the processing result from the output unit 16 constituted by an LCD (Liquid Crystal Display), a speaker, or the like, for example, via the input / output interface 20 as necessary, or from the communication unit 18. Transmission and further recording on the hard disk 15 are performed.

  In the PC 1, an IEEE1394 I / F (InterFace) 22 that performs communication control conforming to the IEEE1394 standard is connected to the input / output interface 20. The drive 2 is connected to the IEEE1394 I / F 22 via the 1394 cable 4. The CPU 12 can access the drive 2 via the bus 11, the input / output interface 20, the IEEE1394 I / F 22, and the 1394 cable 4, and read / write data from / to the optical disk 3 mounted on the drive 2. .

  Here, the CPU 12 executes programs of the OS and various applications, and these programs can be recorded in advance on a hard disk 15 or a ROM 13 as a recording medium built in the PC 1.

  Alternatively, the program is temporarily stored in a removable recording medium 21 such as a flexible disk, a CD-ROM (Compact Disc Read Only Memory), an MO (Magneto Optical) disk, a DVD (Digital Versatile Disc), a magnetic disk, or a semiconductor memory. It can be stored permanently (recorded). Such a removable recording medium 21 can be provided as so-called package software.

  The program is installed on the PC 1 from the removable recording medium 21 as described above, or transferred from the download site to the PC 1 via a digital satellite broadcasting artificial satellite, or a LAN (Local Area Network), The program can be transferred to the PC 1 via a network such as the Internet. The PC 1 can receive the program transferred in this way by the communication unit 18 and install it in the built-in hard disk 15.

  Next, FIG. 3 is a diagram showing a program executed by the CPU 12 of FIG.

  For example, the OS 30 and the applications 31 to 33 (programs) are installed at least on the hard disk 15 in FIG. 2, and the CPU 12 loads the OS 30 from the hard disk 15 to the RAM 14 when the PC 1 is turned on. And run. Further, for example, when the user requests activation of the application 31, 32, 33 by operating the input unit 17, the CPU 12 loads the application 31, 32, 33 from the hard disk 15 to the RAM 14, and the OS 30. Run under control.

  When the applications 31 to 33 make an access request, which is a request for accessing the optical disc 3 mounted on the drive 2, for example, the OS 30 processes the access request. As a result, in the drive 2, the data requested to be recorded by the access request from the applications 31 to 33 is recorded on the optical disc 3. Alternatively, in the drive 2, data that is requested to be reproduced (read) by the access request from the applications 31 to 33 is read from the optical disc 3 and passed to the application that has made the access request via the OS 30.

  2 are not limited to the three applications 31 to 33, and may be one, two, four, or more.

  However, here, the application 33 that is one of the three applications 31 to 33 installed on the hard disk 15 is an application that imports AV data from outside, edits, records, and plays back AV data. It shall be. Therefore, the application 33 is also referred to as an AV application 33 as appropriate hereinafter.

  The AV application 33 calls a PD_API (PD_API.DLL) 41 that is a DLL (Dynamic Link Library), and issues an access request to the optical disc 3 via the PD_API 41. The PD_API 41 is a DLL that provides a unique API (Application Program Interface) to be described later regarding access to the optical disc 3.

  Next, as the OS 30, for example, Unix (R), Linux, or what is called Windows (R) of Microsoft Corporation, or any other OS can be adopted. For example, Windows (R) NT-based OS is adopted. Note that Windows (R) NT-based OSs currently include "Windows (R) NT", "Windows (R) 2000", and "Windows (R) XP".

  FIG. 4 shows a configuration example of the portion of the OS 30 relating to access to the drive 2 (the optical disk 3 thereof) when the Windows® NT-based OS is adopted as the OS 30.

  In FIG. 4, in particular, the layer configuration of the device driver in the OS 30 is shown so that the relationship with the applications 31 to 33 can be understood.

  An OS 30 that is a Windows® NT-based OS is based on microkernel technology and object-oriented technology, and each service is implemented by a subsystem.

  The Win32 SubSystem 51 is one of the subsystems, and provides various APIs (functions) to the applications 31 to 33, and performs, for example, memory management, process management, graphics drawing, and the like.

  That is, for example, when an API function related to I / O (Input / Output) is called from the applications 31 to 33, the Win32 subsystem 51 sends an I / O request corresponding to the API function to the NT I / O manager ( (NT I / O Manager) 52.

  Note that API functions provided by the Win32 subsystem 51 include, for example, CreateFile () for generating a file, ReadFile () for reading a file (data recorded in a file), and a file (data to a file). There are WriteFile () for writing, DeviceIoControl () for various other processes, and the like.

  The NT input / output manager 52 provides a service for passing an IRP (I / O Request Packet) to a device driver having a layer structure.

  Here, the IRP is a packet having processing information requested to the device driver, and the IRP requests, for example, a code (code) for classifying the content of the request and reading (reproduction) of data (file). There are IRP_MJ_READ, IRP_MJ_WRITE for requesting data writing (recording), IRP_MJ_CREATE for requesting file generation, and IRP_MJ_DEVICE_CONTROL for requesting various other processes. In the IRP of IRP_MJ_DEVICE_CONTROL, IOCTL (I / O Control) is specified as a subcode, and this IOCTL can be defined as a user.

  In the NT input / output manager 52, for example, an I / O request according to CreateFile () by the Win32 subsystem 51 is converted into an IRP of IRP_MJ_CREATE. Also, for example, ReadFile () and WriteFile () are converted into IRPs of IRP_MJ_READ and IRP_MJ_WRITE, respectively, and DeviceIoControl () is converted into an IRP of IRP_MJ_DEVICE_CONTROL.

  Here, in the Windows (R) NT-based OS, the IRP is used in a layer higher than the storage class driver layer.

  In FIG. 4, as a device driver of a layer higher than the storage class driver layer, a PD storage 55 that is a storage class driver, a PD_FS 54 that is a file system driver (FileSystem Driver) of a layer one level higher than the storage class driver, and a file system There are three device drivers of the PD filter 53 which is a file system filter driver (FileSystem Filter Driver) in a layer one level higher than the driver.

  Therefore, in the present embodiment, the NT input / output manager 52 provides a service for passing the IRP to the PD filter 53, PD_FS 54, and PD storage 55.

  Specifically, the NT input / output manager 52 converts an I / O request from the Win32 subsystem 51 into an IRP and outputs it to the PD filter 53, for example. Then, the PD filter 53 outputs a request according to the IRP from the NT input / output manager 52, for example, to the NT input / output manager 52. The NT input / output manager 52 converts the request from the PD filter 53 into an IRP. Then, the data is output to the PD_FS 54 of the next lower layer. Further, when the PD_FS 54 outputs a request according to the IRP from the NT input / output manager 52 to, for example, the NT input / output manager 52, the NT input / output manager 52 converts the request from the PD_FS 54 into an IRP. The data is output to the PD storage 55 of the lower layer.

  The PD filter 53 is a file system filter driver for the drive 2 that is a PD drive, and is a file system filter driver that is an upper layer of the PD_FS 54 described later. The PD filter 53 performs filtering of file system requests and other requests related to the file system supplied from the applications 31 to 33 via the Win32 subsystem 51 and the NT input / output manager 52. As a result, a request to be passed to the PD_FS 54 is obtained, and processing such as outputting to the PD_FS 54 via the NT input / output manager 52 is performed.

  The PD filter 53 has a filter core 53A, and main processing in the PD filter 53 such as filtering of requests from the applications 31 to 33 is performed by the filter core 53A. Further, the PD filter 53 performs request filtering by referring to information set (stored) in the registry 58 which is a Windows (R) registry, for example.

  The PD_FS 54 is a file system driver for the drive 2 that is a PD drive, and manages files recorded (recorded) on the optical disc 3 that is a PD mounted in the drive 2. That is, the PD_FS 54 makes a request for writing or reading a file requested from the PD filter 53 via the NT input / output manager 52 based on, for example, a file system as management information of data (file) recorded on the optical disc 3. And output to the PD storage 55 via the NT input / output manager 52.

  Here, the file system driver generally has a cache function of a file stream (File Stream) (file of data recorded (recorded) in a file) and file meta information (File Meta). According to the cache function, for example, the cached file stream and file meta information can be obtained at high speed without actually accessing the optical disc 3.

  In a Windows (R) NT-based OS, an NT cache manager 59 has a cache function, and the PD_FS 54 uses the NT cache manager 59 to provide a cache function.

  The PD_FS 54 has an FS core 54A, and main processing in the PD_FS 54 is performed by the FS core 54A.

  The PD storage 55 is a storage class driver that corresponds to an actual device driver of the drive 2 that is a PD drive, and an IRP as a request that is supplied from the PD_FS 54 that is a device driver of a higher layer via the NT input / output manager 52. For example, it is converted into a SCSI (Small Computer System Interface) code (SCSI Code) and output to an SBP (Serial Bus Protocol) 2 driver 56.

  Here, the reason why the IRP is converted into the SCSI code in the PD storage 55 is that the SCSI code has a good affinity with SBP2 handled by the SBP2 driver 56 in the subsequent stage.

  The SBP2 driver 56 converts the SCSI code from the PD storage 55 into SBP2 data, which is data compliant with SBP2 (converted into the SBP2 protocol), and supplies it to a 1394 bus driver 57.

  Here, in the present embodiment, SBP2 is adopted as a protocol that can handle the file system in communication conforming to the IEEE1394 standard controlled by the 1394 bus driver 57 following the SBP2 driver 56, but SBP2 It is also possible to adopt a protocol other than.

  The 1394 bus driver 57 controls the IEEE1394 I / F 22 (FIG. 2) to transmit the SBP2 data from the SBP2 driver 56 to the drive 2 and to read from the optical disk 3 transmitted from the drive 2. Received data.

  Here, in the present embodiment, communication conforming to the IEEE1394 standard is performed between the PC 1 and the drive 2, but other communication can be performed between the PC 1 and the drive 2. is there. In this case, instead of the 1394 bus driver 57, a bus driver corresponding to communication between the PC 1 and the drive 2 is used.

  In FIG. 4, the PD_API 41 used by the AV application 33 among the applications 31 to 33 provides a unique API (API function) as described above. That is, when the unique API function is called from the AV application 33, the PD_API 41 uses the API function DeviceIoCotrol () provided by the Win32 subsystem 51 in accordance with the API function, so that the user-defined IOCTL is changed. The IRP of the designated IRP_MJ_DEVICE_CONTROL is supplied to the PD filter 53 via the NT input / output manager 52. Thereby, the PD_API 41 controls a unique function of the PD filter 53, that is, a function represented by the user-defined IOCTL.

  The AV application 33 including such a PD_API 41 is recorded on, for example, the removable recording medium 21 (FIG. 2) together with the PD filter 53, the PD_FS 54, and the PD storage 55 necessary for using the drive 2 which is a PD drive. Can be sold. Further, the removable recording medium 21 on which the AV application 33 including the PD_API 41, the PD filter 53, the PD_FS 54, and the PD storage 55 are recorded is sold separately, for example, bundled with the drive 2 and attached as an accessory of the drive 2 Can be sold.

  4, the applications 31 to 33 and the Win32 subsystem 51 operate in the user mode (User Mode), and the NT input / output manager 52, PD filter 53, PD_FS 54, PD storage 55, SBP2 driver 56, The 1394 bus driver 57 operates in a kernel mode.

  Furthermore, in FIG. 4, the NT input / output manager 52 passes the IRP to the file system filter driver or the file system driver by passing the PD filter 53 that is the file system filter driver or the PD_FS 54 that is the file system driver. The NT input / output manager 52 of the Windows (R) NT-based OS passes the FastIO to the file system filter driver and file system driver in addition to the IRP. Can be done.

  That is, the NT input / output manager 52 provides a service for passing FastIO in addition to the IRP to the file system filter driver and the file system driver. Request processing.

  Therefore, the file system filter driver and file system driver of the NT (R) OS of Windows (R) generally support both IRP and FastIO.

  According to FastIO, for example, file reading (Read) and writing (Write) are performed directly to the NT cache manager 59.

  In the following, for example, IRP is used among IRP and FastIO. However, the functions described below can also be realized by FastIO.

  Next, referring to the flowchart of FIG. 5, when access to the optical disc 3 is requested from the applications 31 to 33, the PD filter 53, PD_FS 54, PD storage 55, SBP2 driver 56, 1394 bus driver in the OS 30 of FIG. An outline of the process 57 will be described.

  In the following description and the drawings after FIG. 5, the description and illustration of the Win32 subsystem 51 and the NT input / output manager 52 are omitted as appropriate.

  For example, when the applications 31 to 33 call an API function that requests access to the optical disc 3, a request corresponding to the API function is supplied from the Win32 subsystem 51 to the NT input / output manager 52. The IRP corresponding to the request from the Win32 subsystem 51 is supplied to the PD filter 53.

  In step S1, the PD filter 53 receives the IRP from the NT input / output manager 52 and proceeds to step S2. In step S2, the PD filter 53 filters the IRP from the NT input / output manager 52, proceeds to step S3, and queues the IRP to be supplied to the PD_FS 54. That is, the PD filter 53 supplies and stores the IRP from the NT input / output manager 52 in a queue not shown in FIG.

  Further, the PD filter 53 reads the IRP stored in the queue, supplies it to the PD_FS 54 via the NT input / output manager 52, and proceeds to step S4.

  In step S4, the PD_FS 54 performs a cache process as a process necessary for using the cache function of the NT cache manager 59 for the data requested by the IRP from the PD filter 53, and proceeds to step S5. It is determined whether the data requested by the IRP from the PD filter 53 is cached in the NT cache manager 59.

  If it is determined in step S5 that the data requested by the IRP from the PD filter 53 is cached in the NT cache manager 59, the process proceeds to step S6, and the PD_FS 54 is requested by the IRP from the PD filter 53. For example, an application that calls an API function corresponding to the IRP via the PD filter 53 and the Win32 subsystem via the PD filter 53 and the Win32 subsystem. To any one of 33).

  On the other hand, if it is determined in step S5 that the data requested by the IRP from the PD filter 53 is not cached in the NT cache manager 59, the process proceeds to step S7, and the PD_FS 54 performs the IRP from the PD filter 53. Then, the data is supplied to the PD storage 55 via the NT input / output manager 52, and the process proceeds to step S8.

  In step S8, the PD storage 55 converts the IRP from the PD_FS 54 into a corresponding SCSI code, supplies it to the SBP2 driver 56, and proceeds to step S9. In step S9, the SBP2 driver 56 converts the SCSI code from the PD storage 55 into SBP2 data, supplies it to the 1394 bus driver 57, and proceeds to step S10.

  In step S10, the 1394 bus driver 57 transmits the SBP2 data from the SBP2 driver 56 to the drive 2 by controlling the IEEE1394 I / F 22 (FIG. 2).

  The 1394 bus driver 57 waits for a response to the SBP2 data transmitted in step S10 from the drive 2, receives the response in step S11, and receives the response, SBP2 driver 56, PD storage 55, PD_FS54. The IRP received in step S1 is returned to the application (in FIG. 4, one of the applications 31 to 33) via the PD filter 53 and the Win32 subsystem 51.

  By the way, in FIG. 4, if any one of the applications 31 to 33 accesses the optical disc 3 before any one of the applications accesses the optical disc 3, the one application accesses the optical disc 3. When this occurs, a seek occurs in the drive 2.

  When one application tries to access the optical disc 3 and another application is accessing the optical disc 3, the one application is awaited to access the optical disc 3.

  On the other hand, in FIG. 4, the application 33 among the applications 31 to 33 is an AV application that performs writing (recording) and reading (reproduction) of AV data on the optical disk 3 that is a PD.

  Therefore, when the drive 2 which is a PD drive is designed so that AV data can be read and written in real time with respect to the access of only the AV application 33, the application 31 or 32 can access the optical disc 3. If a seek occurs or the AV application 33 waits for access, the AV application 33 is prevented from reading and writing AV data in real time.

  Therefore, the PD filter 53 is mounted with one or more of the following first to third functions, and any one of the mounted functions prevents reading / writing of AV data from / to the optical disc 3 in real time. It is designed to ensure that AV data is read and written in real time.

  That is, according to the first function, the PD filter 53 sets a specific priority for the IRP corresponding to the access request to the optical disc 3 from the applications 31 to 33, and the specific priority is set. Store the IRP in the queue. Then, the PD filter 53 processes the IRP stored in the queue according to the priority set in the IRP. Thereby, the PD filter 53 preferentially processes, for example, an IRP from the AV application 33 (an IRP corresponding to an access request from the AV application 33), and guarantees the AV application 33 to read and write AV data in real time. .

  FIG. 6 shows a configuration example of the PD filter 53 in which the first function as described above is mounted. In FIG. 6, applications 31 to 33 are also illustrated.

  In the OS 30 that is an NT-based OS of Windows®, an application is executed in units called processes. Furthermore, one or more threads are assigned to the execution of the process, and the process is executed in the thread.

  In FIG. 6, the application 31 is composed of two processes 71 and 72. The process 71 is executed by two threads 71A and 71B, and the process 72 is executed by one thread 72A.

  The application 32 is composed of one process 73, and the process 73 is executed by two threads 73A and 73B.

  Further, the AV application 33 is composed of two processes 74 and 75. The process 74 is executed by two threads 74A and 74B, and the process 75 is executed by one thread 75A. The process 75 is a PD_API 41 process.

  The API function call to the Win32 subsystem 51 can be performed in units of threads. Therefore, in the embodiment of FIG. 6, the API function can be called in each of the threads 71A, 71B, 72A, 73A, 73B, 74A, 74B, and 75A.

  An API function call from a thread can be regarded as an API function call from a process executed in the thread.

  When an API function is called in the threads 71A to 75A, an IRP corresponding to the API function is supplied from the NT input / output manager 52 to the PD filter 53.

  In the PD filter 53, the filter core 53A sets a specific priority (hereinafter referred to as IRP priority as appropriate) regarding access to the optical disc 3 for the IRP from the NT input / output manager 52.

  That is, the OS 30 that is an NT-based OS of Windows® has a so-called standard priority function that sets a priority for a process and further a thread and processes the process or the thread according to the priority. According to this standard priority function, for example, the resources of the CPU 12, the RAM 14, and other PCs 1 are preferentially allocated to processes or threads having a high priority set by the OS 30.

  Therefore, by setting a higher priority than the processes 71 and 72 of the application 31 and the process 73 of the application 32 to the processes 74 and 75 of the AV application 33 by the standard priority function of the OS 30, for example, The application 33 can access the optical disc 3 with priority over the applications 31 and 32.

  However, the standard priority function of the OS 30 affects not only access to the optical disc 3 but also the use of the CPU 12 and access to the RAM 14.

  Therefore, when the priority of the AV application 33 (the process) is set high by the standard priority function of the OS 30, the process of an important service provided by the OS 30 waits for a long time to use the CPU 12 and the RAM 14. May be. As a result, the service is equivalent to being stopped. In the worst case, for example, the PC 1 is hung up.

  Therefore, in the PD filter 53, the filter core 53A sets an IRP priority independent of (not related to) the priority by the standard priority function for the IRP from the NT input / output manager 52.

  The IRP priority is a priority of access to the optical disc 3. Therefore, when a high IRP priority is set for the AV application 33 (its process), other processes including the process of the service provided by the OS 30 are restricted by the IRP priority. However, the use of the CPU 12 and RAM 14 is not limited. For this reason, according to the IRP priority, it is possible to prevent the important service provided by the OS 30 from being stopped and the PC 1 from being hung up.

  When the IRP priority is set for the IRP from the NT input / output manager 52, the filter core 53A of the PD filter 53 supplies the IRP to the queue 81A or 81B and stores it. That is, the queues 81A and 81B store the IRP with the IRP priority set supplied from the filter core 53A.

  Here, in the embodiment of FIG. 6, assuming that there are two volumes (Volume) in the drive 2 which is a PD drive, for example, two queues 81A and 81B are provided as queues for the two volumes. It has been. The PD filter 53 supplies the IRP for the volume corresponding to the queue 81A of the two volumes to the queue 81A, and supplies the IRP for the volume corresponding to the queue 81B to the queue 81B. Hereinafter, the queues 81A and 81B are simply referred to as the queue 81 unless there is a particular need to distinguish them.

  The PD filter 53 processes the IRP stored in the queue 81 according to the IRP priority set in the IRP. That is, the PD filter 53 preferentially reads an IRP having a higher IRP priority from the queue 81 and supplies it to the PD_FS 54 of the lower layer via the NT input / output manager 52.

Note that the thread for the PD filter 53 to perform the processing of the first function as described above (the same applies to the second and third functions described later) is the file system filter driver layer that is the PD filter 53 layer. Create with layers. A queue 81 for storing the IRP is also created in the file system filter driver layer.

  The PD filter 53 uses the first function to preferentially process the IRP from the AV application 33 over the IRP from the applications 31 and 32, for example, an IRP of a process ID (ProcessID) registered in itself. Sets the maximum IRP priority (the maximum value that the IRP priority can take), and sets the minimum IRP priority (the minimum value that the IRP priority can take) for an IRP with an unregistered process ID To do.

  That is, the OS 30 assigns a unique process ID to the process and manages each process, and the IRP from each process (the IRP corresponding to the API function called by each process) is Has the process ID of the process. When the process ID of the IRP from a certain process received from the NT input / output manager 52 matches the process ID registered in the PD filter 53, the PD filter 53 gives the maximum IRP priority to the IRP. If there is no match (including the case where the process ID is not registered), the minimum IRP priority is set for the IRP.

  Here, for example, 5 bits can be adopted as data representing the IRP priority. In this case, the maximum IRP priority is 31 and the minimum IRP priority is 0.

  On the other hand, the PD_API 41 used (loaded) by the AV application 33 uses the API function DeviceIoControl () provided by the Win32 subsystem 51 at the time of loading in order to use the first function of the PD filter 53. Of the processes 74 and 75 of the AV application 33, registration of the process ID of the process 75 that loads itself is requested. That is, when the AV application 33 is activated and loaded by the process 75 of the AV application 33, the PD_API 41 requests an API function DeviceIoControl () that requests the PD filter 53 to register the process ID assigned to the process 75. ).

  In addition, the PD_API 41 requests the PD filter 53 to delete the process ID assigned to the process 75 (deletion of the registered process ID) when the process 75 loaded with the PD_API 41 ends. Call.

  Therefore, as long as the process 75 of the PD_API 41 exists, the PD filter 53 does not handle the IRP from the process 75 (the IRP corresponding to the API function provided by the Win32 subsystem 51 called by the process 75 (PD_API 41)). The maximum IRP priority is set.

  Next, FIG. 7 illustrates the control provided by the PD_API 41 to the AV application 33 for controlling the PD filter 53 when the PD filter 53 performs the processing of the first function (for controlling the PD filter 53). API (function) is shown.

  In FIG. 7, PdGetPriority () and PdSetPriority () are prepared as control API functions provided to the AV application 33 in order for the PD_API 41 to control the PD filter 53.

  API functions PdGetPriority () and PdSetPriority () both take a process ID and an IRP priority as arguments.

  Then, the API function PdGetPriority () is called by specifying the process ID of the argument, and the IRP priority set by the PD filter 53 for the process of the process ID specified by the argument is set in the argument. return. Furthermore, the API function PdGetPriority () returns 1 as the return value when the IRP priority set by the PD filter 53 for the process with the process ID specified by the argument is successful, and the return value when it fails. Returns 0 as.

  Therefore, according to the API function PdGetPriority (), the IRP priority set by the PD filter 53 can be recognized for the IRP from any process.

  When the API function PdSetPriority () is called by specifying the process ID and IRP priority of the argument, the IRP priority set by the PD filter 53 for the process of the process ID specified by the argument is specified by the argument. Change to IRP priority. Further, the API function PdSetPriority () returns 1 as a return value when the IRP priority set by the PD filter 53 is successfully changed, and returns 0 as a return value when the change is unsuccessful.

  Therefore, according to the API function PdSetPriority (), for example, the IRP set by the PD filter 53 with respect to the IRP from the process ID that matches the process ID registered in the PD filter 53 or the process ID that does not match. The priority can be changed.

  When the API function PdGetPriority () is called, the PD_API 41 calls an API function DeviceIoControl () that requests the PD filter 53 for the IRP priority set by the PD filter 53.

  When the API function PdSetPriority () is called, the PD_API 41 calls an API function DeviceIoControl () that requests the PD filter 53 to change the IRP priority set by the PD filter 53.

  As described above, the PD_API 41 uses the API function DeviceIoControl () for requesting registration of the process ID, the API function DeviceIoControl () for requesting deletion of the process ID, in order to use the first function of the PD filter 53. Calls an API function DeviceIoControl () that requests the IRP priority set by the PD filter 53 and an API function DeviceIoControl () that requests a change in the IRP priority set by the PD filter 53 as necessary.

  When the API function DeviceIoControl () is called, the Win32 subsystem 51 makes a request according to the API function DeviceIoControl () to the NT I / O manager 52, and the NT I / O manager 52 sends the request to the IRP_MJ_DEVICE_CONTROL. And is supplied to the PD filter 53.

  In the IRP of this IRP_MJ_DEVICE_CONTROL, as described above, IOCTL is specified as a subcode that can be defined by the user.

  FIG. 8 shows a user-defined IOCTL specified by IRP_MJ_DEVICE_CONTROL when the PD filter 53 performs the process of the first function.

  In FIG. 8, four IOCTLs IOCTL_PD_SET_PROCESSID, IOCTL_PD_DELETE_PROCESSID, IOCTL_PD_SET_RRIORITY, and IOCTL_PD_GET_RRIORITY are prepared as user-defined IOCTLs.

  IOCTL_PD_SET_PROCESSID is an IOCTL that is an IRP subcode of IRP_MJ_DEVICE_CONTROL corresponding to the API function DeviceIoControl () (request according to) that requests registration of a process ID. The API function DeviceIoControl () that requests registration of a process ID takes, for example, the process ID that requests the registration as an argument, and IOCTL_PD_SET_PROCESSID requests registration of the process ID that is the argument to the PD filter 53. IOCTL to do.

  IOCTL_PD_DELETE_PROCESSID is an IOCTL that is an IRP subcode of IRP_MJ_DEVICE_CONTROL corresponding to the API function DeviceIoControl () that requests deletion of a process ID. The API function DeviceIoControl () that requests deletion of the process ID takes, for example, the process ID that requests the deletion as an argument, and IOCTL_PD_DELETE_PROCESSID deletes the process ID that is the argument from the PD filter 53. The requested IOCTL.

  IOCTL_PD_SET_RRIORITY is an IOCTL that is a subcode of the IRP_MJ_DEVICE_CONTROL IRP corresponding to the API function DeviceIoControl () that requests the change of the IRP priority set in the PD filter 53, and requests the change of the IRP priority set in the PD filter 53 Requests that the IRP priority set in the IRP of the process ID that is an argument of the API function PdSetPriority () in FIG. 7 corresponding to the API function DeviceIoControl () is also changed to the IRP priority that is the argument. IOCTL.

  IOCTL_PD_GET_RRIORITY is an IOCTL that is an IRP subcode of IRP_MJ_DEVICE_CONTROL corresponding to the API function DeviceIoControl () that requests the IRP priority set by the PD filter 53, and an API function DeviceIoControl (that requests the IRP priority set by the PD filter 53 ) Corresponding to the API function PdGetPriority () in FIG. 7 is an IOCTL that requests the IRP priority set in the IRP of the process ID.

  Note that the user-defined IOCTL, which is the IRP subcode of IRP_MJ_DEVICE_CONTROL as described above, is passed from the Win32 subsystem 51 to the NT I / O manager 52 using the API function DeviceIoControl () provided by the Win32 subsystem 51. In the NT input / output manager 52, the IRP_MJ_DEVICE_CONTROL IRP subcode is designated.

  Next, an overview of the processing of the AV application 33, the PD_API 41, and the PD filter 53 in FIG. 6 when the PD filter 53 has the first function will be described with reference to the flowchart in FIG.

  When the AV application 33 is activated, the AV application 33 loads the PD_API 41 by the process 75 of the processes 74 and 75 of the AV application 33 in step S21. When the PD_API 41 is loaded by the process 75, in step S31, the API function DeviceIoControl () that requests registration of the process ID of the process 75 that loaded the PD_API 41 is called, and by calling this API function DeviceIoControl (), An IRP of IRP_MJ_DEVICE_CONTROL in which IOCTL_PD_SET_PROCESSID that requests registration of a process ID is specified as IOCTL is supplied from the NT input / output manager 52 to the PD filter 53.

  In step S41, the PD filter 53 receives the IRP from the NT input / output manager 52, and registers the process ID of the process 75 of the PD_API 41 in accordance with IOCTL_PD_SET_PROCESSID of the IRP.

  Therefore, thereafter, unless the process ID of the process 75 of the PD_API 41 is deleted in the PD filter 53, the maximum IRP priority is set for the IRP from the process 75, and the minimum is set for the IRP from other processes. IRP priority is set. Thereby, in the PD filter 53, the IRP from the process 75 of the PD_API 41 is preferentially processed (with the highest priority).

  That is, for example, when the AV application 33 calls an API function ReadFile () that requests reading of a file, for example, as an access request to the optical disc 3 in step S22, the PD_API 41 reads the API function ReadFile in step S32. The call of () is received, and the process proceeds to step S33.

  In step S33, the PD_API 41 calls the same API function ReadFile () (API function ReadFile () provided by the Win32 subsystem 51) in response to a call to the API function ReadFile () from the AV application 33. The IRP of IRP_MJ_READ requesting reading of the file is supplied from the NT input / output manager 52 to the PD filter 53.

  In step S42, the PD filter 53 receives the IRP_MJ_READ IRP from the NT input / output manager 52 and sets the IRP priority for the IRP_MJ_READ IRP.

  That is, in this case, the IRP of IRP_MJ_READ received by the PD filter 53 is from the PD_API 41 (process 75). In step S 41, the process ID of the process 75 of PD_API 41 is registered in the PD filter 53. Therefore, the maximum IRP priority is set to the IRP of IRP_MJ_READ received by the PD filter 53 from the process 75 of the PD_API 41 in step S42.

  As a result, in the PD filter 53, the IRP_MJ_READ IRP from the process 75 of the PD_API 41 is immediately processed unless there is an IRP for which the maximum IRP priority is set.

  That is, in step S43, the PD filter 53 preferentially supplies the IRP_MJ_READ IRP from the process 75 of the PD_API 41 to the PD_FS 54.

  Thereafter, when the AV application 33 is terminated, for example, in step S23, the AV application 33 requests the PD_API 41 (the process 75) to unload.

  When there is a request for unloading, the PD_API 41 calls an API function DeviceIoControl () for requesting deletion of the process ID of its own process 75 in step S34, and by calling this API function DeviceIoControl (), the process ID of the process 75 is called. An IRP of IRP_MJ_DEVICE_CONTROL in which IOCTL_PD_DELETE_PROCESSID for requesting deletion is specified as IOCTL is supplied from the NT input / output manager 52 to the PD filter 53.

  In step S44, the PD filter 53 receives the IRP from the NT input / output manager 52, and deletes the process ID of the process 75 of the PD_API 41 in accordance with IOCTL_PD_DELETE_PROCESSID of the IRP.

  Therefore, thereafter, in the PD filter 53, the IRP is processed according to the priority set by the standard priority function of the OS 30.

  Next, processing of the first function by the PD filter 53 of FIG. 6 will be described with reference to the flowcharts of FIGS. 10 and 11.

  First, referring to the flowchart of FIG. 10, the PD filter 53 of FIG. 6 that implements the first function performs processing from when an IRP is received until the IRP is stored in the queue 81 (to the queue 81). Input processing) will be described.

  An API function that requests an I / O-related process for the drive 2 (performs an I / O request) in any one of the applications 31 to 33 (any one of the processes 71 to 75 in FIG. 6). Is called, the NT input / output manager 52 supplies an IRP corresponding to the API function to the PD filter 53 in response to the API function call (the request output by the Win32 subsystem 51).

  In the PD filter 53, in step S51, the filter core 53A receives the IRP from the process that called the API function (the IRP supplied from the NT input / output manager 52 in response to the API function call by the process), and In step S52, it is determined whether or not the IRP is an IRP (IRP of IRP_MJ_DEVICE_CONTROL) in which IOCTL_PD_SET_PROCESSID (FIG. 8) is designated as IOCTL.

  If it is determined in step S52 that the IRP from the process (the IRP received by the filter core 53A in step S51) is an IRP for which IOCTL_PD_SET_PROCESSID is specified, the process proceeds to step S53, and the filter core 53A determines that the IRP The included process ID, that is, the process ID of the process that called the API function corresponding to the IRP is registered (stored), and the process returns to step S51.

  That is, the IRP for which IOCTL_PD_SET_PROCESSID is specified includes the process ID of the process that called the API function corresponding to the IRP, and the filter core 53A registers the process ID. Here, the process ID registered in the filter core 53A is hereinafter referred to as a registered process ID as appropriate.

  On the other hand, if it is determined in step S52 that the IRP from the process is not an IRP for which IOCTL_PD_SET_PROCESSID is designated, the process proceeds to step S54, and the filter core 53A designates IOCTL_PD_DELETE_PROCESSID (FIG. 8) as the IOCTL. It is determined whether it is an IRP (IRP of IRP_MJ_DEVICE_CONTROL).

  If it is determined in step S54 that the IRP from the process is an IRP for which IOCTL_PD_DELETE_PROCESSID is specified, the process proceeds to step S55, and the filter core 53A deletes (deletes) the registered process ID, and the process returns to step S51.

  If it is determined in step S54 that the IRP from the process is not an IRP for which IOCTL_PD_DELETE_PROCESSID is specified, the process proceeds to step S56, and the filter core 53A requests that the IRP request access to the optical disc 3. Determine if it is an IRP.

  When it is determined in step S56 that the IRP from the process is not the IRP of the access request, that is, the IRP from the process requests a change in the IRP priority set by the PD filter 53, for example. IOCTL_PD_SET_RRIORITY (FIG. 8) If IRP_MJ_DEVICE_CONTROL IRP specified as IOCTL or IOCTL_PD_GET_RRIORITY (FIG. 8) for requesting the IRP priority set by the PD filter 53 is IRP_MJ_DEVICE_CONTROL IRP specified as IOCTL, etc., proceed to step S57. The filter core 53A performs processing according to the IRP, and returns a response corresponding to the processing result to the process that called the API function corresponding to the IRP via the NT input / output manager 52 and the Win32 subsystem 51. Return to step S51.

  Here, in step S57, for example, when the IRP from the process is an IRP for which IOCTL_PD_SET_RRIORITY (FIG. 8) is specified, the filter core 53A sets the IRP from the process with the process ID specified by the IOCTL_PD_SET_RRIORITY. A process of changing the IRP priority to be set to the IRP priority specified in IOCTL_PD_SET_RRIORITY is performed. In step S57, for example, when the IRP from the process is an IRP for which IOCTL_PD_GET_RRIORITY (FIG. 8) is specified, the filter core 53A sets the IRP from the process having the process ID specified by the IOCTL_PD_GET_RRIORITY. The IRP priority to be returned is returned as a response.

  On the other hand, when it is determined in step S56 that the IRP from the process is the IRP of the access request, that is, the IRP from the process requests, for example, an IRP of IRP_MJ_READ that requests a file read or a file write. If the IRP_MJ_WRITE is an IRP, the process proceeds to step S58, and the filter core 53A sets the process ID included in the IRP from the process, that is, the process ID of the process that called the API function corresponding to the IRP, as the registered process ID. Determine whether they match.

  If it is determined in step S58 that the process ID included in the IRP from the process does not match the registered process ID, the process proceeds to step S59, where the filter core 53A determines the minimum IRP priority ( Set (set) the minimum value of possible values of the IRP priority, and proceed to step S61.

  If it is determined in step S58 that the process ID included in the IRP from the process matches the registered process ID, the process advances to step S60, and the filter core 53A determines the maximum IRP priority for the IRP from the process. (The maximum value of the possible values of the IRP priority) is set, and the process proceeds to step S61.

  In step S61, the filter core 53A outputs the IRP from the process in which the IRP priority is set in step S59 or S60 to the queue 81 for storage (queuing), and waits for the next IRP to be supplied. Then, the process returns to step S51.

  In FIG. 10, when the process ID included in the IRP from the process does not match the registered process ID, a minimum IRP priority is set for the IRP from that process, and the process included in the IRP from the process. When the ID matches the registration process ID, the maximum IRP priority is set for the IRP from that process, but it matches the IRP of the process ID that does not match the registration process ID, or the registration process ID. The IRP priority set for the IRP of the process ID can be another value of the IRP priority.

  Also, the IRP priority set for an IRP with a certain process ID, such as an IRP with a process ID that matches the registered process ID, can be specified by, for example, the API function PdSetPriority () described with reference to FIG.

  Furthermore, as the registration process ID, not only one process ID but also a plurality of process IDs can be registered. In this case, a unique IRP priority is associated with each of the plurality of registered process IDs, and a unique IRP priority associated with the registered process ID is set in the IRP of the process ID that matches a certain registered process ID. It is possible to do so.

  Next, with reference to the flowchart of FIG. 11, processing (output processing from the queue 81) performed on the IRP stored in the queue 81 in the PD filter 53 of FIG. To do.

  In the PD filter 53, the filter core 53A searches the IRP stored in the queue 81 for the one with the highest (highest) IRP priority in step S71, and proceeds to step S72.

  In step S72, the filter core 53A processes the IRP having the highest IRP priority obtained by the search in step S71, and returns to step S71. That is, in step S 72, the filter core 53 A preferentially reads the IRP having the highest IRP priority from the queue 81 and outputs it to the PD_FS 54 via the NT input / output manager 52.

  If a plurality of IRPs are obtained as the IRP with the highest IRP priority as a result of the search in step S71, the filter core 53A uses the standard priority function of the OS 30 or the IRP as a queue. The process is performed according to the storage time stored in 81. That is, the filter core 53A preferentially reads from the queue 81 and outputs to the PD_FS 54, for example, from an IRP from a process with a high priority by a standard priority function or an IRP with a fast storage time.

  As described above, the PD filter 53 sets an IRP priority different from the priority by the standard priority function of the OS 30 for the IRP. Specifically, the maximum IRP priority is set for the IRP from the process with the process ID that matches the registration process ID, and the minimum IRP priority is set for the IRP from the process with a process ID that does not match the registration process ID. Set.

  Then, the PD filter 53 stores the IRP for which the IRP priority is set in the queue 81, and further processes the IRP stored in the queue 81 according to the IRP priority.

  On the other hand, in the AV application 33 (FIG. 6), when the PD_APL 41 is loaded by the process 75, the PD_APL 41 requests the PD filter 53 to register the process ID of the process 75, and the PD filter 53 responds to the request. In response, the process ID of the process 75 of PD_APL 41 is registered.

  Then, the AV application 33 makes an access request to the optical disc 3 from the process 75 of the PD_APL 41.

  Therefore, in the PD filter 53, the IRP as the access request to the optical disc 3 by the AV application 33 is processed with priority over the IRP from the other applications 31 and 32 (process thereof). It is possible to prevent (reduce) the reading / writing of data from / to the optical disc 3 by the AV application 33 due to waiting for the IRP processing or seeking of the drive 2 generated by the IRP processing. Thereby, the AV application 33 can record and reproduce the AV data on the optical disc 3 in real time.

  In order to record and reproduce the AV data on the optical disc 3 in real time, at least while the AV application 33 is recording and reproducing the AV data, the AV application 33 can record the AV data on the optical disc 3. The IRP as an access request may be processed with priority.

  On the other hand, in the above-described embodiment, as described with reference to FIG. 9, the IRP as an access request to the optical disc 3 by the AV application 33 is preferentially processed in the PD filter 53 only while the PD_APL 41 is loaded. Is done.

  Therefore, as described in FIG. 9, the PD_APL 41 is loaded when the AV application 33 is started and unloaded when the AV application 33 is ended. For example, the PD_APL 41 is loaded when AV data is recorded or reproduced in the AV application 33. Alternatively, unloading may be performed when the recording or reproduction is stopped.

  Next, the second function of the PD filter 53 for ensuring that AV data is read and written in real time will be described.

  That is, according to the second function, the PD filter 53 sets a pause flag (permission information) indicating permission or non-permission of IRP processing corresponding to an access request to the optical disc 3 from the applications 31 to 33. The IRPs from the applications 31 to 33 are stored in the queue 81. Then, the PD filter 53 processes the IRP stored in the queue 81 according to the pause flag. Thereby, for example, the PD filter 53 stops IRP processing from applications other than the AV application 33, and processes only IRP from the AV application 33 (IRP corresponding to the access request from the AV application 33). The AV data is guaranteed to be read and written by the AV application 33 in real time.

  That is, the PD filter 53 that implements the second function processes only a specific IRP according to the pause flag, and processes all IRPs in a pause state in which other IRP processes are stopped. One of a run state and a run state.

  The PD filter 53 mounted with the second function as described above is configured, for example, as shown in FIG.

  However, in the PD filter 53 (FIG. 6) in which the second function is implemented, the pause flag is set in the filter core 53A in addition to the process ID registration and the IRP priority setting for the IRP. Further, in the PD filter 53 in which the second function is implemented, the IRP stored in the queue 81 is processed according to the pause flag in addition to the IRP priority in the filter core 53A.

  In order to use the second function of the PD filter 53, the PD_API 41 used in the AV application 33 has an API (function) for controlling the PD filter 53 that sets the state of the PD filter 53 to a pause state or a run state. , Provided to the AV application 33.

  FIG. 12 shows an API function for control (for controlling the PD filter 53) provided by the PD_API 41 to the AV application 33 in order to control the PD filter 53 when the PD filter 53 performs the processing of the second function. Is shown.

  FIG. 12 shows API functions (API functions described for the first time) excluding the API functions for controlling the PD filter 53 described so far.

  In FIG. 12, PdPauseOtherAppIrp () and PdRunOtherAppIrp () are prepared as control API functions provided to the AV application 33 in order for the PD_API 41 to control the PD filter 53.

  According to the API function PdPauseOtherAppIrp (), the PD filter 53 is in a pause state in which only a specific IRP is processed and the processing of the other IRP is stopped. On the other hand, according to the API function PdRunOtherAppIrp (), the PD filter 53 enters a run state in which all IRPs are processed.

  The API functions PdPauseOtherAppIrp () and PdRunOtherAppIrp () both take a volume name for specifying a volume as an argument.

  Then, the API function PdPauseOtherAppIrp () is called by specifying the volume name of the argument, so that the PD filter 53 includes the IRP corresponding to the access request for the volume specified by the volume name specified by the argument. In this state, only a specific IRP is processed and other IRP processes are stopped.

  In addition, when the API function PdRunOtherAppIrp () is called by specifying the volume name of the argument, the PD filter 53 selects all IRPs corresponding to the access request for the volume specified by the volume name specified by the argument. A run state to be processed (to be processed) is set.

  Accordingly, the PD filter 53 can be set to the pause state or the run state for each volume, that is, for each queue corresponding to the volume. For example, in the PD filter 53 of FIG. 6, a pause state or a run state can be set independently for each of the queues 81A and 81B.

  However, in the following, in order to simplify the description, it is assumed that the pause state or the run state is set for both the queues 81A and 81B.

  Note that the API function PdPauseOtherAppIrp () returns 1 as a return value when the PD filter 53 is successfully put into a pause state, and returns 0 as a return value when it fails. Similarly, the API function PdRunOtherAppIrp () also returns 1 as a return value when the PD filter 53 is successfully set to the run state, and returns 0 as a return value when it fails.

  When the API function PdPauseOtherAppIrp () is called, the PD_API 41 calls an API function DeviceIoControl () that requests the PD filter 53 to be in a pause state.

  In addition, when the API function PdRunOtherAppIrp () is called, the PD_API 41 calls an API function DeviceIoControl () that requests the PD filter 53 to enter a run state.

  When the API function DeviceIoControl () is called, the Win32 subsystem 51 makes a request according to the API function DeviceIoControl () to the NT I / O manager 52, and the NT I / O manager 52 sends the request to the IRP_MJ_DEVICE_CONTROL. And is supplied to the PD filter 53.

  In IRP_MJ_DEVICE_CONTROL, as described above, IOCTL is specified as a subcode that can be defined by the user.

  FIG. 13 shows a user-defined IOCTL specified by IRP_MJ_DEVICE_CONTROL when the PD filter 53 performs the process of the second function.

  FIG. 13 shows IOCTLs (user-defined IOCTLs described for the first time) excluding the user-defined IOCTLs described so far, as in FIG.

  In FIG. 13, two IOCTLs IOCTL_PD_PAUSE_OTHERAPPIRP and IOCTL_PD_RUN_OTHERAPPIRP are prepared as user-defined IOCTLs.

  IOCTL_PD_PAUSE_OTHERAPPIRP is an IOCTL that is an IRP subcode of IRP_MJ_DEVICE_CONTROL corresponding to the API function DeviceIoControl () (request according to) that requests to be in a pause state, and is an IOCTL that requests that the PD filter 53 be in a pause state. is there.

  IOCTL_PD_RUN_OTHERAPPIRP is an IOCTL that is an IRP subcode of IRP_MJ_DEVICE_CONTROL corresponding to the API function DeviceIoControl () that requests to be in the run state, and is an IOCTL that requests that the PD filter 53 be in the run state.

  As described above, the user-defined IOCTL that is the IRP subcode of IRP_MJ_DEVICE_CONTROL is passed from the Win32 subsystem 51 to the NT I / O manager 52 using the API function DeviceIoControl () provided by the Win32 subsystem 51. In the NT input / output manager 52, the IRP_MJ_DEVICE_CONTROL IRP subcode is designated.

  Next, an overview of processing of the AV application 33, the PD_API 41, and the PD filter 53 in FIG. 6 when the PD filter 53 has the second function will be described with reference to the flowchart in FIG.

  When the AV application 33 is requested to reproduce AV data recorded on the optical disc 3 or record AV data on the optical disc 3, for example, when the user operates the input unit 17 (FIG. 2), the step is performed. In S91, the API function PdPauseOtherAppIrp () is called.

  In step S101, the PD_API 41 receives a call to the API function PdPauseOtherAppIrp () by the AV application 33, proceeds to step S102, and requests an API function that requests a pause state in response to the call to the API function PdPauseOtherAppIrp (). Call DeviceIoControl (). By calling this API function DeviceIoControl (), an IRP of IRP_MJ_DEVICE_CONTROL in which IOCTL_PD_PAUSE_OTHERAPPIRP for requesting a pause state is specified as IOCTL is supplied from the NT input / output manager 52 to the PD filter 53.

  In step S111, the PD filter 53 receives the IRP from the NT input / output manager 52, and sets the pause flag representing the pause state, for example, 1 according to the IOCTL_PD_PAUSE_OTHERAPPIRP of the IRP. Become.

  While in the pause state, the PD filter 53 stops IRP processing from processes other than the PD_API 41 process 75 (FIG. 6), and processes only IRP from the PD_API 41 process 75.

  That is, for example, when the AV application 33 calls an API function ReadFile () for requesting reading of a file, for example, as an access request to the optical disc 3 in step S92, the PD_API 41 reads the API function ReadFile in step S103. The call of () is received, and the process proceeds to step S104.

  In step S104, the PD_API 41 calls the same API function ReadFile () in response to a call to the API function ReadFile () from the AV application 33, and the IRP of IRP_MJ_READ that requests reading of the file is input to the NT by this call. It is supplied from the output manager 52 to the PD filter 53.

  In step S112, the PD filter 53 receives the IRP_MJ_READ IRP from the NT input / output manager 52, and proceeds to step S113. In step S113, the PD filter 53 stores the IRP received in step S112, that is, the IRP from the process 75 of the PD_API 41 in the AV application 33, in the queue 81 (FIG. 6), and further reads out from the queue 81 to the PD_FS 54. Supply.

  As described above, in the PD filter 53, the IRP from the process 75 of the AV application 33 is immediately processed.

  On the other hand, the processes 71 to 73 of the applications 31 and 32 other than the AV application 33 call, for example, an API function ReadFile () for requesting reading of a file as an access request to the optical disc 3 in steps S81 to S83, respectively. By this call, the IRP_MJ_READ IRP requesting the file reading is supplied from the NT input / output manager 52 to the PD filter 53.

  In steps S114 to S116, the PD filter 53 receives an IRP corresponding to the API function ReadFile () call performed by the processes 71 to 73 in steps S81 to S83, and stores the IRP in the queue 81.

  In this case, since the PD filter 53 is in a paused state, the PD filter 53 is a process other than the IRP stored in the queue 81 in steps S114 to S116, that is, a process other than the process 75 of the AV application 33. IRPs from 71 to 73 are not processed. That is, in the PD filter 53, the IRPs from the processes 71 and 72 of the application 31 and the process 73 of the application 32 are not supplied to the PD_FS 54 but are stored in the queue 81.

  Thereafter, for example, when the user operates the input unit 17 (FIG. 2) to request the stop of reproduction of AV data recorded on the optical disc 3 or the termination of the AV application 33, the AV application 33 is requested. Calls the API function PdRunOtherAppIrp () in step S93.

  In step S105, the PD_API 41 receives a call to the API function PdRunOtherAppIrp () by the AV application 33, and proceeds to step S106. In response to the call to the API function PdRunOtherAppIrp (), the PD_API 41 requests to enter the run state. Call DeviceIoControl (). By calling this API function DeviceIoControl (), an IRP of IRP_MJ_DEVICE_CONTROL in which IOCTL_PD_RUN_OTHERAPPIRP for requesting a run state is specified as IOCTL is supplied from the NT input / output manager 52 to the PD filter 53.

  In step S117, the PD filter 53 receives the IRP from the NT input / output manager 52, and in accordance with the IOCTL_PD_RUN_OTHERAPPIRP of the IRP, resets the pause flag to represent a run state, for example, 0, thereby Become.

  When the PD filter 53 enters the run state, it starts (restarts) IRP processing from processes other than the PD_API 41 process 75 (FIG. 6).

  In other words, in this case, in the PD filter 53, the IRPs from the processes 71 to 73 received in steps S114 to S116 are stored in the queue 81 without being processed.

  Therefore, the PD filter 53 reads the IRPs from the processes 71 to 73 that have been stored in the queue 81 in steps S118 to S120, respectively, and supplies them to the PD_FS 54.

  Then, after that, any of the processes 31 to 73 of the application 31 and 32 other than the AV application 33, for example, an API function ReadFile () that requests reading of a file as an access request to the optical disc 3 in step S84. When this is called, an IRP of IRP_MJ_READ requesting reading of the file is supplied from the NT input / output manager 52 to the PD filter 53 by this call.

  In step S121, the PD filter 53 receives the IRP corresponding to the call of the API function ReadFile () performed by any of the processes 71 to 73 in step S84, and stores it in the queue 81.

  In this case, since the PD filter 53 is in the run state, the IRP stored in the queue 81 in step S121 is read in step S122 and supplied to the PD_FS 54 in the PD filter 53.

  As described above, the PD filter 53 outputs only the IRP from the AV application 33 to the PD_FS 54 in the pause state. When the pause state is canceled, that is, when the PD filter 53 enters the run state, the IRP from an application other than the AV application 33 is also output to the PD_FS 54.

  Next, processing of the second function by the PD filter 53 of FIG. 6 will be described with reference to the flowcharts of FIGS. 15 and 16.

  First, referring to the flowchart of FIG. 15, the PD filter 53 of FIG. 6 that implements the second function performs processing from when an IRP is received until the IRP is stored in the queue 81 (to the queue 81). Input processing) will be described.

  According to the processing according to the flowchart of FIG. 15, processing similar to that described with reference to the flowchart of FIG. 10 is performed except for the processing of steps S156 to S159 related to the setting of the pause flag.

  That is, I / O-related processing for the drive 2 is requested (I / O request is performed) in any one of the applications 31 to 33 (any one of the processes 71 to 75 in FIG. 6). When the API function is called, the NT input / output manager 52 supplies the IRP corresponding to the API function to the PD filter 53 in response to the call of the API function.

  In the PD filter 53, in step S151, the filter core 53A receives the IRP from the process that called the API function (the IRP supplied from the NT input / output manager 52 in response to the API function call by the process), Proceeding to step S152, it is determined whether the IRP is an IRP (IRP of IRP_MJ_DEVICE_CONTROL) in which IOCTL_PD_SET_PROCESSID (FIG. 8) is designated as IOCTL.

  If it is determined in step S152 that the IRP from the process (the IRP received by the filter core 53A in step S151) is the IRP for which IOCTL_PD_SET_PROCESSID is specified, the process proceeds to step S153, and the filter core 53A The included process ID, that is, the process ID of the process that called the API function corresponding to the IRP is registered (stored), the next IRP is supplied, and the process returns to step S151.

  That is, in step S153, the process ID of the process that called the API function corresponding to the IRP received by the filter core 53A in step S151 is set as the registration process ID.

  On the other hand, if it is determined in step S152 that the IRP from the process is not an IRP for which IOCTL_PD_SET_PROCESSID is specified, the process proceeds to step S154, and the filter core 53A specifies IOCTL_PD_DELETE_PROCESSID (FIG. 8) as the IOCTL. It is determined whether it is an IRP (IRP of IRP_MJ_DEVICE_CONTROL).

  If it is determined in step S154 that the IRP from the process is an IRP for which IOCTL_PD_DELETE_PROCESSID is specified, the process proceeds to step S155, and the filter core 53A deletes (deletes) the registered process ID and supplies the next IRP. The process returns to step S151.

  If it is determined in step S154 that the IRP from the process is not an IRP for which IOCTL_PD_DELETE_PROCESSID is specified, the process proceeds to step S156, and the filter core 53A determines that the IRP from the process is IOCTL_PD_PAUSE_OTHERAPPIRP (FIG. 13). Is the specified IRP (IRP of IRP_MJ_DEVICE_CONTROL).

  If it is determined in step S156 that the IRP from the process is an IRP for which IOCTL_PD_PAUSE_OTHERAPPIRP is specified, the process proceeds to step S157, and the filter core 53A sets the variable pause flag to 1 representing the pause state. After waiting for the next IRP supply, the process returns to step S151. As a result, the filter core 53A (PD filter 53) is in a pause state.

  If it is determined in step S156 that the IRP from the process is not an IRP for which IOCTL_PD_PAUSE_OTHERAPPIRP is specified, the process advances to step S158, and the filter core 53A determines that the IRP from the process is IOCTL_PD_RUN_OTHERAPPIRP (FIG. 13). Is the specified IRP (IRP of IRP_MJ_DEVICE_CONTROL).

  If it is determined in step S158 that the IRP from the process is an IRP for which IOCTL_PD_RUN_OTHERAPPIRP is specified, the process proceeds to step S159, and the filter core 53A resets the pause flag as a variable to 0 representing the run state. After waiting for the next IRP to be supplied, the process returns to step S151. As a result, the filter core 53A enters the run state.

  If it is determined in step S158 that the IRP from the process is not an IRP for which IOCTL_PD_RUN_OTHERAPPIRP is specified, the process proceeds to step S160, and the filter core 53A requests that the IRP request access to the optical disc 3. Determine if it is an IRP.

  If it is determined in step S160 that the IRP from the process is not the IRP of the access request, that is, the IRP from the process requests a change in the IRP priority set by the PD filter 53, for example. IOCTL_PD_SET_RRIORITY (FIG. 8) If IRP_MJ_DEVICE_CONTROL IRP specified as IOCTL or IOCTL_PD_GET_RRIORITY (FIG. 8) for requesting the IRP priority set by PD filter 53 is IRP_MJ_DEVICE_CONTROL IRP specified as IOCTL, etc., proceed to step S161. The filter core 53A performs processing according to the IRP, as in step S57 of FIG. Further, the filter core 53A returns a response corresponding to the processing result to the process calling the API function corresponding to the IRP via the NT input / output manager 52 and the Win32 subsystem 51, and waits for the next IRP supply. Then, the process returns to step S151.

  On the other hand, when it is determined in step S160 that the IRP from the process is the IRP of the access request, that is, the IRP from the process requests, for example, an IRP of IRP_MJ_READ that requests reading of a file or a file write. If the IRP_MJ_WRITE is an IRP, the process advances to step S162, and the filter core 53A includes the process ID included in the IRP from the process, that is, the process ID of the process that called the API function corresponding to the IRP, as the registered process ID. Determine whether they match.

  When it is determined in step S162 that the process ID included in the IRP from the process does not match the registered process ID, the process proceeds to step S163, and the filter core 53A sets the minimum IRP priority for the IRP from the process. Set and proceed to step S165.

  If it is determined in step S162 that the process ID included in the IRP from the process matches the registered process ID, the process proceeds to step S164, and the filter core 53A determines the maximum IRP priority for the IRP from the process. Is set, and the process proceeds to step S165.

  In step S165, the filter core 53A outputs and stores the IRP from the process, for which the IRP priority is set in step S163 or S164, to the queue 81, waits for the next IRP supply, and returns to step S151.

  Next, with reference to the flowchart of FIG. 16, processing (output processing from the queue 81) performed on the IRP stored in the queue 81 in the PD filter 53 of FIG. 6 that implements the second function will be described. To do.

  In the PD filter 53, the filter core 53A determines whether or not the pause flag is set to 1 in step S171.

  If it is determined in step S171 that the pause flag is set to 1, that is, if the PD filter 53 is in the paused state, the process proceeds to step S172, and the queue 81 has the maximum IRP priority (IRP priority). Determine whether there is an IRP for which the maximum possible value)) is set.

  In step S 172, when it is determined that there is an IRP in which the maximum IRP priority is set in the queue 81, that is, an IRP from a process having a process ID that matches the registered process ID is stored in the queue 81. In step S173, the filter core 53A processes the IRP stored in the queue 81 and having the maximum IRP priority, and returns to step S171. That is, in step S173, the filter core 53A reads the IRP for which the maximum IRP priority is set from the queue 81 and outputs it to the PD_FS 54 via the NT input / output manager 52.

  In step S172, when it is determined that there is no IRP in which the maximum IRP priority is set in the queue 81, that is, the IRP from the process having the process ID that matches the registered process ID is stored in the queue 81. If not, the process skips step S173 and returns to step S171.

  Therefore, when the PD filter 53 is in a paused state, a process ID that does not match the registered process ID regardless of whether or not the IRP from the process with the process ID that matches the registered process ID is stored in the queue 81. The IRP from the process is not output to the PD_FS 54.

  On the other hand, if it is determined in step S171 that the pause flag is reset to 0, that is, if the PD filter 53 is in the run state, the process proceeds to steps S174 and S175 in sequence, and steps S71 and S72 in FIG. The same processing as in the case of is performed.

  That is, in step S174, the filter core 53A searches the IRP stored in the queue 81 for the highest (highest) IRP priority, and proceeds to step S175.

  In step S175, the filter core 53A processes the IRP having the highest IRP priority obtained by the search in step S174, and returns to step S171. That is, in step S175, the filter core 53A preferentially reads the IRP having the highest IRP priority from the queue 81 and outputs it to the PD_FS 54 via the NT input / output manager 52.

  Therefore, when the PD filter 53 is in the run state, the PD filter 53 reads the IRP from the queue 81 and outputs it to the PD_FS 54 as in the case of FIG.

  As described above, the PD filter 53 sets the maximum IRP priority for the IRP from the process with the process ID matching the registration process ID, and the IRP from the process with the process ID not matching with the registration process ID Set the minimum IRP priority.

  Then, the PD filter 53 stores the IRP for which the IRP priority is set in the queue 81. In the run state, the PD filter 53 processes the IRP stored in the queue 81 according to the IRP priority, but in the pause state. Among the IRPs stored in the queue 81, only the IRP for which the maximum IRP priority is set, that is, the IRP from the process whose process ID matches the registered process ID is processed.

  Therefore, the AV application 33 (FIG. 6) requests the PD filter 53 to register the process ID of the process 75 in the PD_APL 41 loaded by the process 75, and the AV application 33 records and reproduces AV data. When the PD filter 53 is requested to enter the pause state when performing the above, the PD filter 53 sets the maximum IRP priority for the IRP from the process 75 of the PD_APL 41, and further increases the maximum IRP priority. Only the IRP for which the IPR priority is set, that is, the IRP from the process 75 of the PD_APL 41 is processed (output to the PD_FS 54).

  Since only the IRP from the process 75 of the PD_APL 41 is processed in this way, the optical disc by the AV application 33 is waited for the IRP processing from the applications 31 and 32, the seek of the drive 2 generated by the IRP processing, etc. It is possible to prevent the reading and writing of data from 3 from being hindered. Thereby, the AV application 33 can record and reproduce the AV data on the optical disc 3 in real time.

  Here, according to the first function, if the IRP from the process 75 of the PD_APL 41 is not stored in the queue 81, the IRP from the application 31 or 32 (the process) is output from the PD filter 53 to the PD_FS 54. sell. On the other hand, according to the second function, when the PD filter 53 is in the paused state, the IRP from the process 75 of the PD_APL 41 is stored, of course, when stored in the queue 81. Even when there is no IRP, the IRP from the application 31 or 32 (the process) is not output from the PD filter 53 to the PD_FS 54.

  In the case described with reference to FIGS. 15 and 16, only the IRP for which the maximum IRP priority is set is output to the PD_FS 54 as the specific IRP in the PD filter 53 in the paused state. In addition, for example, it is possible to output only the IRP of the process ID that matches the registered process ID to the PD_FS 54 by using the IRP of the process ID that matches the registered process ID as a specific IRP. That is, the PD filter 53 can simply output an IRP having a process ID that matches the registered process ID to the PD_FS 54 without setting the IRP priority.

  Next, a third function of the PD filter 53 for ensuring that AV data is read and written in real time will be described.

  That is, according to the third function, the PD filter 53 is a functional switch for turning on / off the output of the IRP from the application other than the AV application 33, that is, the applications 31 and 32 (process thereof) to the PD_FS 54. The IRP from the applications 31 and 32 is prevented from being output to the PD_FS 54 by the functional switch. As a result, the PD filter 53 does not output the IRP from the applications 31 and 32 other than the AV application 33 to the PD_FS 54, and outputs only the IRP from the AV application 33 to the PD_FS 54. Guarantees reading and writing in

  FIG. 17 shows a configuration example of the PD filter 53 in which the third function as described above is mounted.

  In FIG. 17, the filter core 53 of the PD filter 53 includes a switch 101 as a functional switch (Switch) for turning on / off the output of the IRP from the applications 31 and 32 other than the AV application 33 to the PD_FS 54. ing.

  The switch 101 is turned on or off according to the switch setting information stored in the registry 58, for example, when the OS 30 is started (Boot) or when the optical disk 3 is loaded (Inject) into the drive 2. Note that the state of the switch 101 cannot be switched after the volume corresponding to the drive 2 is mounted on the PC 1, for example.

  Here, the switch setting information is stored in the registry 58 when the AV application 33 is installed, for example. That is, when the AV application 33 is installed, the user selects whether the switch 101 is turned on or off, and the state of the selected switch 101 is stored in the registry 58 as switch setting information. Remembered. Note that the switch setting information stored in the registry 58 can be changed after installation of the AV application 33 on a screen or the like for setting options of the AV application 33.

  When the switch 101 is in the on state, the switch 101 outputs IRPs from all applications (applications 31 to 33 in FIG. 17) to the PD_FS 54.

  On the other hand, when the switch 101 is in the OFF state, only the IRP from the PD_API 41 (or its process) in the AV application 33 is output to the PD_FS 54, and the other applications 31 and 32 (or their processes) are driven. 2 (the file system) corresponding to (the optical disk 3 mounted on) is camouflaged. As a result, the switch 101 does not need to output the IRP from the other applications 31 and 32 to the PD_FS 54.

  Here, the switch 101 in the OFF state has a volume mounted for an IRP other than the PD_API 41, but the volume is read-only (Read Only). A status indicating that (File) and directory (Directory) do not exist is returned as a response.

  As a result, when the switch 101 is in the OFF state, the drive 2 is a volume having no file or directory on Windows (R) Explorer, and further, a file drop, an eject operation, a format (Format) ) It is treated as a volume that cannot be operated.

  Next, processing of the third function by the PD filter 53 of FIG. 17 will be described with reference to the flowchart of FIG.

  For example, when the OS 30 is activated or the optical disk 3 is loaded in the drive 2, the filter core 53A acquires switch setting information from the registry 58 in step S191, and proceeds to step S192.

  In step S192, the filter core 53A sets the switch 101 to the on or off state according to the switch setting information.

  Then, the filter core 53A waits for an IRP to be supplied from any of the applications 31 to 33, proceeds to step S193, receives the IRP, and proceeds to step S194.

  In step S194, the filter core 53A determines whether the IRP received in step S193 (performed immediately before) is an IRP from the AV application 33 (PD_API 41). If it is determined in step S194 that the IRP received in step S193 is the IRP from the AV application 33, the process proceeds to step S195, and the filter core 53A outputs the IRP to the PD_FS 54, and the applications 31 to 33 are processed. After waiting for the next IRP to be supplied from any of the above, the process returns to step S193.

  If it is determined in step S194 that the IRP received in step S193 is not an IRP from the AV application 33, that is, if the IRP received in step S193 is an IRP from the application 31 or 32, In step S196, the filter core 53A determines whether or not the switch 101 is off.

  If it is determined in step S196 that the switch 101 is not in the off state, that is, if the switch 101 is in the on state, the process proceeds to step S195, and the filter core 53A determines the IRP received in step S193. , Output to the PD_FS 54, wait for the next IRP to be supplied from any of the applications 31 to 33, and return to step S193.

  If it is determined in step S196 that the switch 101 is in the OFF state, the process advances to step S197, and the switch 101 determines whether or not the application 31 or 32 that is the output source of the IRP received in step S193. File system impersonation response that impersonates the file system, that is, for example, as described above, the volume is mounted, but the volume is read-only, and the file and directory do not exist in the volume. Returns the status. Then, after waiting for the next IRP to be supplied from any of the applications 31 to 33, the process returns to step S193, and the same processing is repeated thereafter.

  As described above, in the PD filter 53, when the switch 101 is in the OFF state, only the IRP from the AV application 33 is output to the PD_FS 54. Therefore, waiting for the IRP processing from the application 31 or 32, or the IRP It is possible to prevent the AV application 33 from interfering with the reading / writing of data with respect to the optical disc 3 due to the seek of the drive 2 caused by the above process. Thereby, the AV application 33 can record and reproduce the AV data on the optical disc 3 in real time.

In step S194, whether or not the IRP is the IRP from the AV application 33 (the process 75 loaded with the PD_API 41) is determined by, for example, using the PD filter with the process ID of the process 275 as the registration process ID as described above. It is possible to perform registration based on whether or not the registered process ID and the IRP process ID match.

  In the above case, the first to third functions are mounted on the PD filter 53. However, the first to third functions can be mounted on the PD_FS 54 instead of the PD filter 53. is there.

  By the way, as described in step S4 of FIG. 5, the PD_FS 54 (FIG. 4) is a process necessary for using the cache function of the NT cache manager 59 for the data requested by the IRP from the PD filter 53. Perform cache processing.

  For example, when the data requested by the IRP from the PD filter 53 is cached in the NT cache manager 59, the cached data is returned from the PD_FS 54 to the PD filter 53. When the data requested by the IRP from the filter 53 is not cached in the NT cache manager 59, the IRP from the PD filter 53 is output from the PD_FS 54 to the PD storage 55.

  Therefore, when the data requested by the IRP from the PD filter 53 is not cached in the NT cache manager 59, compared with the case where there is no cache function, the amount of cache processing, that is, the CPU 12 (FIG. 2) As much as the cache processing routine is executed, an extra overhead occurs.

  This overhead delays the output of the IRP from the PD_FS 54 to the PD storage 55. Since the delay in the output of the IRP from the AV application 33 to the PD storage 55 from the PD_FS 54 is a factor that hinders playback and recording of AV data in real time, the IRP from the AV application 33 is It is desirable that there is no such delay.

  Such an IRP delay can be prevented by not using the cache function.

  On the other hand, when no cache function is used, all IRPs from the PD filter 53 are output from the PD_FS 54 to the PD storage 55. That is, all the IRPs from the applications 31 to 33 are output from the PD filter 53 to the PD storage 55 via the PD_FS 54.

  That is, in this case, in addition to the IRP from the AV application 33, all the IRPs from the applications 31 and 32 that are applications other than the AV application 33 are also output from the PD filter 53 to the PD storage 55 via the PD_FS 54. . A seek occurs in the drive 2 in order to read data required by the IRP from the applications 31 and 32.

  This seek prevents reading of AV data requested by the IRP from the AV application 33 in real time.

  On the other hand, when the cache function is used, if the data requested by the IRP from the applications 31 and 32 is cached in the NT cache manager 59, the cached data is transferred from the PD_FS 54 to the PD filter. Returned to 53. In this case, the drive 2 does not generate a seek for reading data requested by the IRP from the applications 31 and 32 from the optical disk 3.

  From the above, in the AV application 33, by not using the cache function, a delay due to the cache process can be prevented, and as a result, the real-time performance of AV data reproduction and recording can be improved.

  Furthermore, in the applications 31 and 32 other than the AV application 33, by using the cache function, it is possible to reduce the occurrence of seek in the drive 2, and as a result, the AV data is reproduced and recorded in real time. Can be improved.

  Therefore, the PD filter 53 processes the IRP from the applications 31 and 32 so as to use the cache function, while the IRP from the AV application 33 sets whether or not the cache function is used and sets the setting. It is possible to implement a cache ON / OFF function that performs processing according to the result.

  FIG. 19 shows a configuration example of the PD filter 53 in which the cache on / off function is implemented.

  Note that the cache on / off function is provided only to the AV application 33 that loads the PD_API 41, and the applications 31 and 32 always use the cache function. That is, the cache on / off function has nothing to do with the applications 31 and 32. For this reason, in FIG. 19, only the AV application 33 provided with the cache on / off function among the applications 31 to 33 is illustrated.

  In FIG. 19, the PD filter 53 has a command buffer 111. The command buffer 111 temporarily stores, for example, an IRP from the AV application 33 (PD_API 41), that is, an IRP output from the NT input / output manager 52 when the PD_API 41 of the AV application 33 calls an API function.

  In the PD filter 53 of FIG. 19, the filter core 53A sets whether or not the cache function is used by the AV application 33 (PD_API 41), and from the AV application 33 stored in the command buffer 111 according to the setting result. Handles IRP.

  That is, the filter core 53A outputs the IRP from the AV application 33 stored in the command buffer 111 to the PD_FS 54 when the setting of whether to use the cache function is set to use the cache function. IRP output control is performed so that the PD_FS 54 uses the cache function.

  Further, the filter core 53A outputs the IRP from the AV application 33 stored in the command buffer 111 to the PD_FS 54 when the setting of whether to use the cache function is set not to use the cache function. In the PD_FS 54, IRP output control is performed so that data is output to the PD storage 55 without using the cache function.

  Next, FIG. 20 shows a control (PD control 53 control) provided to the AV application 33 by the PD_API 41 to control the PD filter 53 when the PD filter 53 performs the cache on / off function processing. ) API (function).

  In FIG. 20, four API functions PdOpenFile (), PdCloseFile (), PdReadFile (), and PdWriteFile () are prepared as control API functions provided to the AV application 33 in order for the PD_API 41 to control the PD filter 53. ing.

  Here, the four API functions PdOpenFile (), PdCloseFile (), PdReadFile (), and PdWriteFile () in FIG. 20 are all API functions for a file stream (File Stream) for performing file operations. These API functions are also provided in the Win32 subsystem 51.

  That is, the PD_API 41 provides unique file stream API functions PdOpenFile (), PdCloseFile (), PdReadFile (), and PdWriteFile () separately from the file stream API functions provided by the Win32 subsystem 51.

  The API function PdOpenFile () is an API function that requests the opening of a file. The file name (including the path name) of the file to be opened, and the open mode when the file is opened (for example, a mode in which only the reference is performed). , And cache information indicating whether or not the cache function is used is taken as an argument.

  Then, by calling the API function PdOpenFile () specifying the argument file name, open mode, and cache information, the file with the file name specified by the argument is opened in the open mode specified by the argument. Is done. Further, the API function PdOpenFile () causes the PD filter 53 (the filter core 53A) to set whether to use the cache function or not according to the cache information of the argument. The API function PdOpenFile () returns a file handle of the opened file as a return value when the file is successfully opened, and returns 0xffffffff as a return value when the file fails to open. Note that 0x indicates that the subsequent value is a hexadecimal number.

  The API function PdCloseFile () is an API function that requests closing of a file, and takes a file handle of the file to be closed as an argument. Then, by calling the API function PdCloseFile () specifying the argument file handle, the file specified by the file handle is closed. The API function PdCloseFile () returns 1 as a return value when the file is successfully closed, and 0 as a return value when the file fails to close.

  The API function PdReadFile () is an API function that requests reading of data from a file, a file handle of a file from which data is to be read, a buffer pointer that is a pointer to a buffer that temporarily stores data read from the file, And the number of bytes as the amount of data to be read from the file is taken as an argument. Then, by calling the API function PdReadFile () with the argument file handle, buffer pointer, and number of bytes, the data of the file specified by the file handle is read by the number of bytes, and the buffer pointer Is stored in the storage area specified by. The API function PdReadFile () returns the number of bytes of the read data as a return value when the data reading is successful, and returns 0 as the return value when the data reading fails. The API function PdReadFile () corresponds to the API function ReadFile () provided by the Win32 subsystem 51.

  The API function PdWriteFile () is an API function that requests writing of data to a file. The file handle of the file to which data is to be written, the buffer pointer that is a pointer to the buffer that temporarily stores the data to be written to the file, and the file The number of bytes as the amount of data to be written is taken as an argument. Then, by calling the API function PdWriteFile () specifying the argument file handle, buffer pointer, and number of bytes, the data of that number of bytes in the storage area specified by the buffer pointer is specified by the file handle. Written to a file. The API function PdWriteFile () returns the number of bytes of the written data as a return value when data writing is successful, and returns 0 as the return value when data writing fails. The API function PdWriteFile () corresponds to the API function WriteFile () provided by the Win32 subsystem 51.

  When the API functions PdOpenFile (), PdCloseFile (), PdReadFile (), and PdWriteFile () are called, the PD_API 41 calls the corresponding API function DeviceIoControl () provided by the Win32 subsystem 51.

  When the API function DeviceIoControl () is called, the Win32 subsystem 51 makes a request according to the API function DeviceIoControl () to the NT I / O manager 52, and the NT I / O manager 52 sends the request to the IRP_MJ_DEVICE_CONTROL. And is supplied to the PD filter 53.

  In this IRP_MJ_DEVICE_CONTROL, as described above, IOCTL is specified as a subcode that can be defined by the user.

  FIG. 21 shows user-defined IOCTLs specified by IRP_MJ_DEVICE_CONTROL when the API functions PdOpenFile (), PdCloseFile (), PdReadFile (), and PdWriteFile () are respectively called.

  In FIG. 21, four IOCTLs IOCTL_PD_OPEN_FILE, IOCTL_PD_CLOSE_FILE, ICCTL_PD_READ_FILE, and IOCTL_PD_WRITE_FILE corresponding to the API functions PdOpenFile (), PdCloseFile (), PdReadFile (), and PdWriteFile () in FIG. 20 are prepared as user-defined IOCTLs. Yes.

  IOCTL_PD_OPEN_FILE is an IOCTL that is an IRP subcode of IRP_MJ_DEVICE_CONTROL corresponding to the API function DeviceIoControl () (requested in response to the API function PdOpenFile ()) and is requested to open the file.

  IOCTL_PD_CLOSE_FILE is an IOCTL that is an IRP subcode of IRP_MJ_DEVICE_CONTROL corresponding to the API function DeviceIoControl () that is called in response to the call of the API function PdCloseFile (), and is an IOCTL that requests the file to be closed.

  IOCTL_PD_READ_FILE is an IOCTL that is an IRP subcode of IRP_MJ_DEVICE_CONTROL corresponding to the API function DeviceIoControl () called in response to the call of the API function PdReadFile (), and is an IOCTL that requests reading of data from the file.

  IOCTL_PD_WRITE_FILE is an IOCTL that is a subcode of IRP of IRP_MJ_DEVICE_CONTROL corresponding to the API function DeviceIoControl () that is called in response to the call of the API function PdWriteFile (), and is an IOCTL that requests data writing to the file.

  As described above, the user-defined IOCTL that is the IRP subcode of IRP_MJ_DEVICE_CONTROL is passed from the Win32 subsystem 51 to the NT I / O manager 52 using the API function DeviceIoControl () provided by the Win32 subsystem 51. In the NT input / output manager 52, the IRP_MJ_DEVICE_CONTROL IRP subcode is designated.

  Next, an overview of the processing of the AV application 33, the PD_API 41, the PD filter 53, and the PD_FS 54 in FIG. 19 when the PD filter 53 has a cache on / off function will be described with reference to the flowchart in FIG. To do.

  When the AV application 33 reads / writes AV data from / to the optical disc 3 without using the cache function, in step S201, the AV application 33 caches an API function PdOpenFile () that requests opening of a file to be read / written by AV data. Call the cache information (Cache OFF) not to use the function as an argument.

  In step S211, the PD_API 41 receives a call to the API function PdOpenFile () by the AV application 33, and proceeds to step S212. In response to the call to the API function PdOpenFile (), the PD_API 41 requests an API function DeviceIoControl ( ). By calling this API function DeviceIoControl (), an IRP of IRP_MJ_DEVICE_CONTROL in which IOCTL_PD_OPEN_FILE requesting file opening is specified as IOCTL is supplied from the NT input / output manager 52 to the PD filter 53. In this case, IOCTL_PD_OPEN_FILE includes cache information indicating that the cache function is not used.

  In step S221, the PD filter 53 receives the IRP from the NT I / O manager 52, and indicates that the cache function is not used according to the IOCTL_PD_OPEN_FILE of the IRP, indicating that the cache function is not used. , Reset (set) to 0, and the file opened by designating cache off by the AV application 33 enters a cache off state in which the cache function is not used.

  While in the cache-off state, the PD filter 53 is the IRP_MJ_DEVICE_CONTROL IRP from the PD_API 41 (the API function DeviceIoControl that the PD_API 41 calls in response to a call to the API function PdOpenFile (), PdCloseFile (), PdReadFile (), or PdWriteFile ()) Corresponding to (), IRP_MJ_DEVICE_CONTROL IRP in which IOCTL_PD_OPEN_FILE, IOCTL_PD_CLOSE_FILE, ICCTL_PD_READ_FILE, or IOCTL_PD_WRITE_FILE is specified, respectively, is output to the PD_FS 54 as the IRP of that IRP_MJ_DEVICE_CONTROL, and is output by the IRP requested by the PD_API 41 IRP output control from the PD_API 41 is performed so that reading and writing are performed without using the cache function.

  That is, in step S221, the PD filter 53 outputs the IRP_MJ_DEVICE_CONTROL IRP specified by IOCTL_PD_OPEN_FILE from the PD_API 41 received from the NT input / output manager 52 to the PD_FS 54 as it is after the cache is turned off.

  In step S <b> 231, the PD_FS 54 receives the IRP_MJ_DEVICE_CONTROL IRP in which IOCTL_PD_OPEN_FILE is specified from the PD filter 53, and outputs it to the PD storage 55. Thereby, the file on the optical disk 3 is opened.

  Thereafter, for example, the AV application 33 requests, for example, an API function PdReadFile () or PdWriteFile () that requests reading or writing of a file (file stream) as an access request to the optical disc 3 in step S202. In step S213, the PD_API 41 receives the API function PdReadFile () or PdWriteFile () call and proceeds to step S214.

  In step S214, the PD_API 41 calls an API function DeviceIoControl () that requests reading or writing of a file in response to a call to the API function PdReadFile () or PdWriteFile () from the AV application 33. IRP_MJ_DEVICE_CONTROL IRP for which IOCTL_PD_READ_FILE requesting read of the IRP is specified as IOCTL, or IRP_MJ_DEVICE_CONTROL for which writing of the file is requested as ICTL_PD_WRITE_FILE is supplied from the I / O manager 52 to the PD filter 53 .

  In step S223, the PD filter 53 receives the IRP_MJ_DEVICE_CONTROL IRP from the NT input / output manager 52, proceeds to step S224, and outputs it to the PD_FS 54.

  Here, as described above, the PD filter 53 in the cache-off state outputs the IRP of IRP_MJ_DEVICE_CONTROL from the PD_API 41 to the PD_FS 54 while maintaining the IRP of the IRP_MJ_DEVICE_CONTROL.

  Therefore, in this case, in step S224, in the PD filter 53, IRP_MJ_DEVICE_CONTROL IRP in which IOCTL_PD_READ_FILE for requesting file reading is specified as IOCTL, or IRP_MJ_DEVICE_CONTROL in which IOCTL_PD_WRITE_FILE for requesting file writing is specified as IOCTL. The IRP is output to the PD_FS 54 while maintaining the IRP of the IRP_MJ_DEVICE_CONTROL.

  In step S232, the PD_FS 54 receives the IRP_MJ_DEVICE_CONTROL IRP from the PD filter 53.

  Here, the PD_FS 54 uses the NT cache for the IRP_MJ_READ or IRP_MJ_WRITE IRP that the NT input / output manager 52 outputs to the PD filter 53 when the API function ReadFile () or WriteFile () provided by the Win32 subsystem 51 is called. A cache function is provided by the manager 59, and the IRP_MJ_DEVICE_CONTROL IRP is not provided with a cache function.

  Therefore, in step S232, the PD_FS 54 that has received the IRP_MJ_DEVICE_CONTROL IRP from the PD filter 53 immediately outputs the IRP to the PD storage 55. That is, in this case, the cache function is not used.

  Thereafter, when the AV application 33 calls the API function PdCloseFile () for requesting the close of the file requested to be opened in step S201 in step S203, the PD_API 41 performs the API function PdCloseFile () of the AV application 33 in step S215. Upon receiving the call, the process proceeds to step S216, and the API function DeviceIoControl () for requesting the close of the file is called according to the call of the API function PdCloseFile (). By calling this API function DeviceIoControl (), an IRP of IRP_MJ_DEVICE_CONTROL in which IOCTL_PD_CLOSE_FILE requesting file close is specified as IOCTL is supplied from the NT input / output manager 52 to the PD filter 53.

  In step S225, the PD filter 53 receives the IRP from the NT input / output manager 52, proceeds to step S226, and outputs it to the PD_FS 54 as it is.

  In step S <b> 233, the PD_FS 54 receives the IRP_MJ_DEVICE_CONTROL IRP in which IOCTL_PD_CLOSE_FILE is specified from the PD filter 53, and outputs it to the PD storage 55. Thereby, the file on the optical disk 3 is closed.

  On the other hand, when the AV application 33 reads / writes AV data from / to the optical disk 3 using the cache function, in step S241, an API function PdOpenFile () for requesting opening of a file to be read / written to AV data is set. Call the cache information (Cache ON) to use the cache function as an argument.

  In step S251, the PD_API 41 receives a call to the API function PdOpenFile () by the AV application 33, and proceeds to step S252. In response to the call to the API function PdOpenFile (), the PD_API 41 requests an API function DeviceIoControl ( ). By calling this API function DeviceIoControl (), an IRP of IRP_MJ_DEVICE_CONTROL in which IOCTL_PD_OPEN_FILE requesting file opening is specified as IOCTL is supplied from the NT input / output manager 52 to the PD filter 53. In this case, IOCTL_PD_OPEN_FILE includes cache information indicating that the cache function is used.

  In step S261, the PD filter 53 receives the IRP from the NT input / output manager 52, and indicates that the cache function is used according to the IOCTL_PD_OPEN_FILE of the IRP indicating that the cache function is used. As a result, a file opened by designating cache on by the AV application 33 is set to a cache on state using the cache function.

  The PD filter 53 controls to read / write data requested by the IRP from the PD_API 41 using the cache function while in the cache-on state.

  That is, in step S261, the PD filter 53 outputs the IRP of IRP_MJ_DEVICE_CONTROL in which IOCTL_PD_OPEN_FILE is specified from the PD_API 41, which is received from the NT input / output manager 52 after the cache is turned on, to the PD_FS 54.

  In step S <b> 271, the PD_FS 54 receives the IRP_MJ_DEVICE_CONTROL IRP in which IOCTL_PD_OPEN_FILE is specified from the PD filter 53, and outputs it to the PD storage 55. Thereby, the file on the optical disk 3 is opened.

  Thereafter, for example, when the AV application 33 calls an API function PdReadFile () or PdWriteFile () for requesting, for example, reading or writing of a file as an access request to the optical disc 3 in step S242, the PD_API 41 In S253, the API function PdReadFile () or PdWriteFile () call is received, and the process proceeds to Step S254.

  In step S254, the PD_API 41 calls an API function DeviceIoControl () that requests reading or writing of a file in response to a call to the API function PdReadFile () or PdWriteFile () from the AV application 33. IRP_MJ_DEVICE_CONTROL IRP for which IOCTL_PD_READ_FILE requesting read of the IRP is specified as IOCTL, or IRP_MJ_DEVICE_CONTROL for which writing of the file is requested as ICTL_PD_WRITE_FILE is supplied from the I / O manager 52 to the PD filter 53 .

  In step S263, the PD filter 53 receives the IRP_MJ_DEVICE_CONTROL IRP from the NT input / output manager 52, proceeds to step S264, and outputs it to the PD_FS 54.

  Here, the IRP_MJ_DEVICE_CONTROL IRP requesting the file read and the IRP_MJ_DEVICE_CONTROL IRP requesting the file read and the IOCTL_PD_WRITE_FILE requesting the file write out of the IRP_MJ_DEVICE_CONTROL IRP from the PD_API 41 are specified for the PD filter 53 in the cache-on state. With respect to the IRP of the IRP_MJ_DEVICE_CONTROL, the IRP is converted and output to the PD_FS 54.

  That is, in step S264, the IRP_MJ_DEVICE_CONTROL IRP in which IOCTL_PD_READ_FILE requesting file reading is specified is input to NT when the API function ReadFile () provided by the Win32 subsystem 51 and requesting file reading is called. The output manager 52 converts the IRP_MJ_READ output to the PD filter 53 and outputs it to the PD_FS 54.

  Also, the IRP_MJ_DEVICE_CONTROL IRP in which IOCTL_PD_WRITE_FILE requesting file writing is specified indicates that the NT I / O manager 52 performs PD filter when WriteFile () requesting file writing provided by the Win32 subsystem 51 is called. It is converted into IRP of IRP_MJ_WRITE to be output to 53 and output to PD_FS 54.

  In step S272, the PD_FS 54 receives the IRP of IRP_MJ_READ or the IRP of MRP_MJ_WRITE from the PD filter 53.

  Here, as described above, the PD_FS 54 provides a cache function by the NT cache manager 59 for the IRP of IRP_MJ_READ or the IRP of IRP_MJ_WRITE.

  Therefore, in step S272, the PD_FS 54 that has received the IRP of IRP_MJ_READ or the IRP_MJ_WRITE IRP from the PD filter 53 uses the cache function to read and write data requested by the IRP.

  That is, for example, when the data requested to be read by the IRP_MJ_READ IRP from the PD filter 53 is cached in the NT cache manager 59, the PD_FS 54 uses the cached data as a response to the PD Return to filter 53. Further, for example, when the data requested to be read by the IRP_MJ_READ IRP from the PD filter 53 is not cached in the NT cache manager 59, the PD_FS 54 uses the IRP_MJ_READ IRP from the PD filter 53 as the PD storage. To 55.

  Thereafter, when the AV application 33 calls the API function PdCloseFile () for requesting the close of the file requested to be opened in step S241 in step S243, the PD_API 41 performs the API function PdCloseFile () of the AV application 33 in step S255. Upon receiving the call, the process proceeds to step S256, and the API function DeviceIoControl () for requesting the close of the file is called in response to the call of the API function PdCloseFile (). By calling this API function DeviceIoControl (), an IRP of IRP_MJ_DEVICE_CONTROL in which IOCTL_PD_CLOSE_FILE requesting file close is specified as IOCTL is supplied from the NT input / output manager 52 to the PD filter 53.

  In step S265, the PD filter 53 receives the IRP from the NT input / output manager 52, proceeds to step S266, and outputs it to the PD_FS 54 as it is.

  In step S <b> 273, the PD_FS 54 receives the IRP_MJ_DEVICE_CONTROL IRP in which IOCTL_PD_CLOSE_FILE is specified from the PD filter 53, and outputs it to the PD storage 55. Thereby, the file on the optical disk 3 is closed.

  When calling the API function PdOpenFile () that requests opening of a file, whether the cache information of the argument is information that the cache function is used or information that the cache information is not used For example, it can be determined according to the performance of the PC 1 or the drive 2 (for example, the operation clock of the CPU 12 or the worst seek time of the drive 2), the user's operation, or the like.

  Next, with reference to the flowchart of FIG. 23, processing of the cache on / off function by the PD filter 53 of FIG. 19 will be described.

  When any of the applications 31 to 33 (process) calls an API function that requests an I / O-related process for the drive 2 (i.e., performs an I / O request), the API function is called. The NT input / output manager 52 supplies an IRP corresponding to the API function to the PD filter 53.

  In the present embodiment, API functions called by applications 31 to 33 (including PD_API 41 of AV application 33) include those provided by PD_API 41 in addition to those provided by Win32 subsystem 32.

  For calling an API function provided by the Win32 subsystem 32, the Win32 subsystem 32 makes a request corresponding to the API function to the NT input / output manager 52, and the NT input / output manager 52 receives the API function. An IRP corresponding to the function is supplied to the PD filter 53. In addition, for calling an API function provided by the PD_API 41, the PD_API 41 calls an API function DeviceIoControl () corresponding to the API function, and the Win32 subsystem 32 requests a request corresponding to the API function DeviceIoControl (). The NT input / output manager 52 supplies the IRP corresponding to the API function DeviceIoControl () to the PD filter 53.

  Therefore, even if the API function called by the applications 31 to 33 is an API function provided by the Win32 subsystem 32 or an API function provided by the PD_API 41, the API function is finally changed to the API function. The corresponding IRP is still supplied from the NT input / output manager 52 to the PD filter 53.

  In step S301, the PD filter 53 receives the IRP supplied from the NT input / output manager 52 in response to the API function call, stores it in the command buffer 111, and proceeds to step S302. In step S302, the filter core 53A determines that the IRP stored in the command buffer 111 (in the immediately preceding step S301) is IOCTL_PD_OPEN_FILE (FIG. 21) for requesting opening of a file as an IRP (IRP of IRP_MJ_DEVICE_CONTROL). ) Is determined.

  Here, the IOCTL_PD_OPEN_FILE includes cache information as described above.

  If it is determined in step S302 that the IRP stored in the command buffer 111 is an IRP for which IOCTL_PD_OPEN_FILE is specified, the process proceeds to step S303, and the filter core 53A has cache information in IOCTL_PD_OPEN_FILE specified by the IRP. Determines whether or not indicates that the cache function is used.

  If it is determined in step S303 that the cache information indicates that the cache function is used, the process proceeds to step S304, and the filter core 53A sets the cache flag as a variable to 1 indicating that the cache function is used. As a result, the cache is turned on and the process proceeds to step S306.

  If it is determined in step S303 that the cache information indicates that the cache function is not used, the process advances to step S305, and the filter core 53A indicates that the cache flag as a variable is not used. It is reset (set) to 0, thereby entering a cache-off state and proceeds to step S306.

  In step S306, the filter core 53A outputs the IRP specified with IOCTL_PD_OPEN_FILE stored in the command buffer 111 to the PD_FS 54, waits for the next IRP to be supplied, and returns to step S301.

  In this case, the PD_FS 54 receives an IRP in which IOCTL_PD_OPEN_FILE is specified from the filter core 53A, and outputs it to the PD storage 55, thereby opening the file.

  On the other hand, if it is determined in step S302 that the IRP stored in the command buffer 111 is not an IRP for which IOCTL_PD_OPEN_FILE is specified, the process proceeds to step S307, and the filter core 53A determines that the IRP stored in the command buffer 111 is As IOCTL, it is determined whether IOCTL_PD_CLOSE_FILE (FIG. 21) for requesting file close is the designated IRP (IRP of IRP_MJ_DEVICE_CONTROL).

  If it is determined in step S307 that the IRP stored in the command buffer 111 is an IRP for which IOCTL_PD_CLOSE_FILE is specified, the process proceeds to step S308, and the filter core 53A specifies the IOCTL_PD_CLOSE_FILE stored in the command buffer 111. The output IRP is output to the PD_FS 54, waits for the next IRP to be supplied, and returns to step S301.

  In this case, the PD_FS 54 receives the IRP in which IOCTL_PD_CLOSE_FILE is specified from the filter core 53A, and outputs it to the PD storage 55, whereby the file is closed.

  If it is determined in step S307 that the IRP stored in the command buffer 111 is not an IRP for which IOCTL_PD_CLOSE_FILE is specified, the process proceeds to step S309, and the filter core 53A determines that the IRP stored in the command buffer 111 is It is determined whether IOCTL_PD_READ_FILE that requests reading of a file or IOCTL_PD_WRITE_FILE (FIG. 21) that requests writing of a file is an IRP (IRP of IRP_MJ_DEVICE_CONTROL) as IOCTL.

  If it is determined in step S309 that the IRP stored in the command buffer 111 is not an IRP for which IOCTL_PD_READ_FILE or IOCTL_PD_WRITE_FILE is specified, the process proceeds to step S310, and the IRP stored in the command buffer 111 is output to the PD_FS 54. After waiting for the next IRP to be supplied, the process returns to step S301.

  If it is determined in step S309 that the IRP stored in the command buffer 111 is an IRP in which IOCTL_PD_READ_FILE or IOCTL_PD_WRITE_FILE is specified, the process proceeds to step 311 and the filter core 53A has a cache flag of 1. Determine whether or not.

  If it is determined in step S311 that the cache flag is 1, that is, if the PD filter 53 (the filter core 53A) is in the cache-on state (set), the process proceeds to step S312 and the filter core 53A converts the IRP stored in the command buffer 111.

  In other words, in this case, the IRP stored in the command buffer 111 is an IRP of IRP_MJ_DEVICE_CONTROL in which IOCTL_PD_READ_FILE requesting file reading or IOCTL_PD_WRITE_FILE (FIG. 21) requesting file writing is designated as IOCTL. .

  When the IRP stored in the command buffer 111 is an IRP of IRP_MJ_DEVICE_CONTROL in which IOCTL_PD_READ_FILE requesting file reading is specified, the filter core 53A, in step S312, the IRP of the IRP_MJ_DEVICE_CONTROL is replaced by the Win32 subsystem 51. When the provided API function ReadFile () is called, the NT input / output manager 52 converts the IRP_MJ_READ IRP output to the PD filter 53.

  If the IRP stored in the command buffer 111 is an IRP of IRP_MJ_DEVICE_CONTROL in which IOCTL_PD_WRITE_FILE requesting file writing is specified, the filter core 53A changes the IRP of the IRP_MJ_DEVICE_CONTROL to the Win32 subsystem in step S312. When the API function WriteFile () provided by 51 is called, the NT input / output manager 52 converts the IRP_MJ_WRITE IRP output to the PD filter 53.

  In step S313, the filter core 53A outputs the IRP after the conversion in step S312, that is, the IRP of IRP_MJ_READ or IRP_MJ_WRITE, to the PD_FS 54, and waits for the next IRP to be supplied to step S301. Return.

  In this case, the PD_FS 54 receives an IRP of IRP_MJ_READ or IRP_MJ_WRITE from the filter core 53A, and reads or writes data requested by the IRP using a cache function.

  That is, as described above, the PD_FS 54 provides a cache function by the NT cache manager 59 for the IRP of IRP_MJ_READ or the IRP of IRP_MJ_WRITE.

  Therefore, for example, when the IRP received by the PD_FS 54 from the filter core 53A is the IRP of IRP_MJ_READ, it is confirmed whether the data requested to be read by the IRP is cached in the NT cache manager 59. When the data requested to be read is cached, the PD_FS 54 returns the cached data to the PD filter 53 as a response. Further, for example, when the data requested to be read by the IRP_MJ_READ IRP from the PD filter 53 is not cached in the NT cache manager 59, the PD_FS 54 uses the IRP_MJ_READ IRP from the PD filter 53 as the PD storage. To 55.

  Here, the PD storage 55 is provided with a read / write buffer (not shown) for reading and writing data. The size of the read / write buffer is, for example, equal to the page size at the time of paging (for example, 4 KB (kilo byte)), and the maximum size of data that can be read and written at a time is the read / write buffer. Limited to size.

  Therefore, the PD_FS 54 reads and writes the IRP of IRP_MJ_READ from the filter core 53A when the size of the data requested to be read by the IRP of IRP_MJ_READ from the filter core 53A exceeds the size of the read / write buffer. The data is divided into a plurality of IRPs of IRP_MJ_READ requesting to read data within the buffer size, and output to the PD storage 55. The same applies to the IRP_MJ_WRITE IRP from the filter core 53A.

  On the other hand, if it is determined in step S311 that the cache flag is not 1, that is, the cache flag is 0, the PD filter 53 (filter core 53A thereof) is in the cache-off state (set). ), The process advances to step S314, and the filter core 53A specifies the IRP stored in the command buffer 111, that is, IOCTL_PD_READ_FILE that requests reading of the file or IOCTL_PD_WRITE_FILE (FIG. 21) that requests writing of the file. The IRP is output to the PD_FS 54 as it is, waits for the next IRP to be supplied, and returns to step S301.

  In this case, the PD_FS 54 receives the IRP of IRP_MJ_DEVICE_CONTROL in which IOCTL_PD_READ_FILE or IOCTL_PD_WRITE_FILE is specified from the filter core 53A, and immediately outputs the IRP to the PD storage 55 without using the cache function. To do.

  That is, as described above, the PD_FS 54 does not provide a cache function for the IRP_MJ_DEVICE_CONTROL IRP and immediately outputs it to the PD storage 55.

  Here, the maximum size of data that can be read and written at a time is limited to the size of the read / write buffer of the PD storage 55 as described above.

  Therefore, if the size of the data requested to be read / written by the IRP_MJ_DEVICE_CONTROL IRP output to the PD_FS 54 in step S314 exceeds the size of the read / write buffer, the filter core 53A reads the IRP_MJ_DEVICE_CONTROL IRP from the read / write The data is divided into a plurality of IRP_MJ_DEVICE_CONTROL IRPs that request reading / writing of data within the buffer size and output to the PD_FS 54.

  Note that the cache function is used or not depending on the cache on / off function only in the IRP_MJ_DEVICE_CONTROL IRP in which the user-defined IOCTL shown in FIG. 21 is specified, and the IRP in which this IOCTL is specified. Is output from the NT input / output manager 52 to the PD filter 53 by calling the API function of FIG. 20 provided only by the PD_API 41.

  Accordingly, in this embodiment, only the AV application 33 that loads the PD_API 41 can use the cache on / off function.

  When the AV function 33 does not use the cache function, the IRP processing delay caused by the overhead of the cache processing for the IRP from the AV application 33 is prevented, and the AV data by the AV application 33 is prevented. The real-time performance of playback and recording can be improved.

  On the other hand, the other applications 31 and 32 request to read or write data by directly calling the API function ReadFile () or WriteFile () provided by the Win32 subsystem 51. Be sure to use the cache function.

  By using this cache function, the frequency with which IRPs from the applications 31 and 32 are output from the PD_FS 54 to the PD storage 55 decreases. As a result, the seek of the drive 2 caused by the reading / writing of the data requested by the IRP from the applications 31 and 32, and the drive caused at the time of reading / writing the data requested by the IRP from the AV application 33 after the data reading / writing 2 can be prevented (reduced), and the AV data can be reproduced and recorded in real time by the AV application 33.

  Next, any one of the first to third functions described above and the cache on / off function can be used in combination.

  FIG. 24 shows a configuration example of the PD filter 53 in the case where either one of the first function and the second function is used in combination with the cache on / off function.

  In FIG. 24, the PD filter 53 sets the IRP priority for the IRP corresponding to the access request to the optical disc 3 from the applications 31 to 33 as described in the processing of the first function, and the IRP The IRP in which the priority is set is stored in the queue 81. Then, the PD filter 53 reads the IRP stored in the queue 81 according to the priority set in the IRP and outputs it to the PD_FS 54.

  Alternatively, as described in the processing of the second function, the PD filter 53 sets a pause flag indicating permission or disapproval of IRP processing corresponding to an access request to the optical disc 3 from the applications 31 to 33. The IRPs from the applications 31 to 33 are stored in the queue 81. Then, the PD filter 53 reads the IRP stored in the queue 81 according to the pause flag and outputs it to the PD_FS 54.

  Further, as described in the processing of the cache on / off function, the PD filter 53 sets whether to use the cache function for the IRP from the AV application 33, and outputs the IRP to the PD_FS 54 according to the setting result. Therefore, the IRP is processed.

  FIG. 25 shows a configuration example of the PD filter 53 when the third function and the cache on / off function are used in combination.

  In FIG. 25, the PD filter 53 turns on the output to the PD_FS 54 of the IRP from the application other than the AV application 33, that is, the applications 31 and 32 (process thereof), as described in the processing of the third function. The IRP from the applications 31 and 32 to the PD_FS 54 by having the functional switch 101 to / off, and turning the functional switch 101 on or off according to the switch setting information stored in the registry 58 Control the output of.

  Further, as described in the processing of the cache on / off function, the PD filter 53 sets whether to use the cache function for the IRP from the AV application 33, and outputs the IRP to the PD_FS 54 according to the setting result. Therefore, the IRP is processed.

  As described above, even when any one of the first to third functions and the cache on / off function are used in combination, the seek caused by the applications 31 and 32 accessing the optical disc 3 is suppressed. Thus, the application 33 can reproduce and record the AV data in real time.

  In the present embodiment, an optical disk is used as a recording medium on which data is recorded and reproduced. However, in the present invention, seeking such as a hard disk or other disk-shaped recording medium occurs. The present invention can be applied when recording and reproducing data on a recording medium.

  Further, in this specification, the processing steps for describing a program for causing the PC 1 to perform various processes do not necessarily have to be processed in time series in the order described in the flowchart, and are executed in parallel or individually. Processing to be performed (for example, parallel processing or object processing) is also included.

It is a block diagram which shows the structural example of one Embodiment of the information processing system to which this invention is applied. 2 is a block diagram illustrating a hardware configuration example of a PC 1. FIG. It is a figure which shows the program which CPU12 runs. It is a block diagram which shows the internal structural example (file system) of OS30. 4 is a flowchart for explaining an overview of processing performed in the OS 30; It is a block diagram which shows the structural example of PD filter 53 which mounted the 1st or 2nd function. It is a figure which shows the API function which PD_API41 provides. It is a figure which shows user-defined IOCTL designated by IRP_MJ_DEVICE_CONTROL. It is a flowchart explaining the process of a 1st function. It is a flowchart explaining the process of a 1st function. It is a flowchart explaining the process of a 1st function. It is a figure which shows the API function which PD_API41 provides. It is a figure which shows user-defined IOCTL designated by IRP_MJ_DEVICE_CONTROL. It is a flowchart explaining the process of a 2nd function. It is a flowchart explaining the process of a 2nd function. It is a flowchart explaining the process of a 2nd function. It is a block diagram which shows the structural example of PD filter 53 which mounted the 3rd function. It is a flowchart explaining the process of a 3rd function. It is a block diagram which shows the structural example of PD filter 53 which mounted the cache on / off function. It is a figure which shows the API function which PD_API41 provides. It is a figure which shows user-defined IOCTL designated by IRP_MJ_DEVICE_CONTROL. It is a flowchart explaining the process of a cache on / off function. It is a flowchart explaining the process of a cache on / off function. It is a block diagram which shows the structural example of PD filter 53 in the case of using either one of a 1st or 2nd function, and a cache on / off function combining. It is a block diagram which shows the structural example of PD filter 53 in the case of using any one of 3rd functions, and a cache on / off function in combination.

Explanation of symbols

  1 PC, 2 drive, 3 optical disk, 4 1394 cable, 11 bus, 12 CPU, 13 ROM, 14 RAM, 15 hard disk, 16 output unit, 17 input unit, 18 communication unit, 19 drive, 20 I / O interface, 21 removable Recording medium, 22 IEEE1394 I / F, 30 OS, 31 to 33 application, 41 PD_API, 51 Win32 subsystem, 52 NT I / O manager, 53 PD filter, 53A filter core, 54 PD_FS, 54A FS core, 55 PD storage, 56 SBP2 driver, 57 1394 bus driver, 58 registry, 59 NT cache manager, 81A, 81B queue, 101 switch, 111 command buffer

Claims (10)

In an information processing apparatus that processes an access request that is a request for access to a recording medium from an application,
Set permission information indicating permission or non-permission of processing of a packet having processing information requested to a device driver corresponding to the access request to the recording medium, and specify a specific application in accordance with the permission information set. said access the corresponding to the request performs a process of the packet, pause state is a state to stop processing the packet that corresponds to the access request from another application, or the access from all the applications from the run state is a state in which the processing of the packet that corresponds to the request, the state setting means for setting as the current state,
Queue control means for storing the packet corresponding to the access request from the application in a queue;
If the current state is the pause state, performs processing of the packet to the correspond to the access request from a specific application of said packet stored in the queue, the current state said run And an access request processing means for processing all the packets stored in the queue when in the state. The information processing apparatus according to claim 1, wherein the state setting unit sets the pause state or the run state as the current state in accordance with a user operation. It further comprises a cache function setting means for setting whether to use the cache function,
Said access request processing means further in accordance with the cache function setting means by use whether the setting result of the caching, according to claim 1, characterized in that performing the processing of the packet corresponding to the access request Information processing device. Said access request processing unit, according to claim 3, characterized in that the only processing of the packet corresponding to the access request from a specific application, in accordance with the setting result of the presence or absence of use of the cache function Information processing device. The information processing apparatus according to claim 1, wherein the information processing apparatus is a filter driver that filters the packet corresponding to the access request and passes the packet to a file system driver. The information processing apparatus according to claim 1, wherein the data read from and written to the recording medium includes at least AV (Audio Visual) data. The recording medium reserves a free area closest to the recording area in which data was recorded immediately before, among the continuous free areas of a predetermined size or more on the recording area, and records data. The information processing apparatus according to claim 1, wherein: In an information processing method for processing an access request that is a request for access to a recording medium from an application,
Set permission information indicating permission or non-permission of processing of a packet having processing information requested to a device driver corresponding to the access request to the recording medium, and specify a specific application in accordance with the permission information set. said access the corresponding to the request performs a process of the packet, pause state is a state to stop processing the packet that corresponds to the access request from another application, or the access from all the applications from the run state is a state in which the processing of the packet that corresponds to the request, the state setting step of setting as the current state,
A queue control step for storing the packet corresponding to the access request from an application in a queue;
If the current state is the pause state, performs processing of the packet to the correspond to the access request from a specific application of said packet stored in the queue, the current state said run And an access request processing step for processing all of the packets stored in the queue when it is in a state. In a program that causes a computer to process an access request, which is a request for access to a recording medium from an application,
Set permission information indicating permission or non-permission of processing of a packet having processing information requested to a device driver corresponding to the access request to the recording medium, and specify a specific application in accordance with the permission information set. said access the corresponding to the request performs a process of the packet, pause state is a state to stop processing the packet that corresponds to the access request from another application, or the access from all the applications from the run state is a state in which the processing of the packet that corresponds to the request, the state setting step of setting as the current state,
A queue control step for storing the packet corresponding to the access request from an application in a queue;
If the current state is the pause state, performs processing of the packet to the correspond to the access request from a specific application of said packet stored in the queue, the current state said run And an access request processing step for processing all of the packets stored in the queue when it is in a state. In a program recording medium in which a program for causing a computer to process an access request that is a request for access to the recording medium from an application is recorded.
Set permission information indicating permission or non-permission of processing of a packet having processing information requested to a device driver corresponding to the access request to the recording medium, and specify a specific application in accordance with the permission information set. said access the corresponding to the request performs processing of said packet, pause state, in that stop processing of the packet that corresponds to the access request from another application, or the access from all the applications from the run state is a state in which the processing of the packet that corresponds to the request, the state setting step of setting as the current state,
A queue control step for storing the packet corresponding to the access request from an application in a queue;
If the current state is the pause state, performs processing of the packet to the correspond to the access request from a specific application of said packet stored in the queue, the current state said run And an access request processing step for processing all the packets stored in the queue when in a state. A program recording medium on which a program is recorded.

Images