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

Abstract

The present invention relates to an information processing device for processing an access request for accessing a recording medium from an application program, which includes the following components: a setting unit for setting a unique priority for an access request from an application program or setting an indication of priority for an access request from an application program The permission information of whether the processing of the access request of the application program is allowed; the queue controller is used to store the access requests provided with priority or permission information in the queue; and the access request processor is used to store the access requests according to the priority or permission information Process access requests stored in the queue.

Description

Information processing apparatus and method, program, and program recording medium

technical field

The present invention relates to an information processing device and method, a program, and a program recording medium. More specifically, the present invention relates to an information processing apparatus and method, a program, and a program recording medium in which, for example, audio-visual data (AV data) can be recorded and played back from the recording medium in real time.

Background technique

There is a great demand for recording and playback of high bit rate AV data to and from optical discs.

The assignee of the present invention previously proposed an optical disc drive for recording various data formats such as video data and audio data associated therewith in Japanese Unexamined Patent Application Publication No. 2004-005895, which The optical disc can be periodically recorded in units of, for example, sectors of the optical disc (without recording in adjacent sectors), and more specifically, the boundaries of video data and audio data can be made to coincide with the boundaries of sectors of the optical disc.

In this optical disc drive, a certain amount of video data or audio data can be collectively recorded on a continuous storage area on the optical disc, so that such data can be read or written without seeking.

In addition, since video data or audio data is recorded in units of disc sectors, video data or audio data need not be recorded together in one sector to make it possible to read only video data or audio data. That is, for example, when the user only needs video data or audio data, the required video data or audio data can be read out from the optical disc, which improves the performance of only video data and audio data when they are simultaneously recorded in one sector. The efficiency (speed) of reading video data (or audio data).

Contents of the invention

The assignee of the present invention has also proposed an optical disk drive of the following type. The continuous free area on the optical disc has at least a predetermined size on which the free area adjacent to the recorded recording area is reserved so that data can be recorded on the reserved space.

In this case, ideally, a certain data string can be recorded in a continuous recording area on the optical disc. Therefore, data can be recorded or played back without seeking so that high bit rate AV data can be recorded on or played back from the optical disc in real time.

The above-described optical disc drive capable of recording and playing back data without seeking is referred to as a "Professional Disc (PD) drive" hereinafter. A disc on which data is recorded using a PD drive is hereinafter referred to as a "Professional Disc (PD)".

High-performance yet inexpensive computers are possible due to the use of faster central processing units (CPUs) and lower-priced mass storage devices. In such a computer, an application (program) executes processing such as editing a large amount of AV data (hereinafter referred to as "AV application").

There is a rapidly growing need to install a PD drive in a computer or externally connect the PD drive to the computer in order to enable AV applications to access the PD drive to read/write AV data to/from the PD.

However, in this case, it cannot be guaranteed that AV data is read/written from/to PD in real time.

More specifically, in current computers, in general, a plurality of application programs can be executed simultaneously by using multitasking operations. But, specifically, time-sharing processing is performed on multiple applications. Therefore, for example, if another application has already accessed the PD before the AV application accesses the PD, an unexpected lookup may occur in the PD driver when the AV application accesses the PD.

Furthermore, when another application is already accessing the PD when the AV application tries to access the PD, it has to wait.

In the case described above, it is difficult to read AV data from or write to the PD in real time.

It is therefore desirable to be able to record or read data on or from a recording medium such as an optical disc in real time.

An information processing apparatus according to an embodiment of the present invention can process an access request from an application program to access a recording medium. The information processing device includes: a setting device for setting the priority level dedicated to the access request from the application program or permission information indicating whether the access request from the application program has been allowed; queue control means for sequentially storing access requests; and access request processing means for sequentially processing the stored access requests according to priority or permission information.

The setting means may set the priority of the access request from the prescribed application higher than the priority of access from other applications.

The access request processing means may continuously process an access request from a prescribed application and process an access request from another application only when the permission information indicates that the access request has been permitted.

The information processing apparatus may further include cache function setting means for setting whether to use the cache function. The access request processing means may process the access request depending on whether the cache function is used.

The access request processing means may process an access request from a prescribed application depending on whether the cache function is used.

The information processing device may also be a filter driver for filtering access requests and sending the filtered access requests to the file system driver.

Data read from or written to the recording medium may include at least audio-visual data.

In the recording area of the recording medium, among continuous free areas having at least a predetermined size, a free area closest to a recording area in which data has been temporarily stored may be reserved and data may be recorded in the reserved free area.

An information processing method for processing an access request from an application program to a recording medium according to an embodiment of the present invention includes the steps of: setting a priority dedicated to an access request from an application program or indicating whether the access request from an application program has been blocked permission information allowed; storing the access requests in order according to the provided priority or permission information; and processing the stored access requests in order according to the priority or permission information.

According to an embodiment of the present invention, the program for allowing a computer to process an access request from an application program to access a recording medium includes the following steps: setting a priority level dedicated to the access request from the application program or indicating whether the access request from the application program has been allowed permission information; storing the access requests in order according to the provided priority or permission information; and processing the stored access requests in order according to the priority or permission information.

A program recording medium according to an embodiment of the present invention has recorded thereon a program that allows a computer to process an access request from an application program for accessing the recording medium. The procedure includes the steps of: setting a priority dedicated to an access request from an application program or permission information indicating whether an access request from an application program has been allowed; storing the access requests in order according to the provided priority or permission information; and The stored access requests are processed sequentially based on priority or permission information.

According to an embodiment of the present invention, in response to an access request from an application program, a priority specific to the access request or permission information indicating whether the access request has been permitted is set. Access requests are stored in order according to the provided priority or permission information. The stored access requests are then processed sequentially according to priority or permission information.

According to an embodiment of the present invention, access requests from a certain application can be prioritized, or only access requests from a specified application can be accepted. Therefore, data can be recorded or played back in real time.

Description of drawings

FIG. 1 is a block diagram showing a structural example of an information processing system according to an embodiment of the present invention;

2 is a block diagram showing an example of a hardware configuration of a personal computer (PC);

Figure 3 illustrates the program executed by the CPU;

4 is a block diagram showing an example of an internal structure (file system) of an operating system (OS);

FIG. 5 is a flow chart of the entire processing flow executed by the OS;

6 is a block diagram showing the structure of a PD filter performing a first function or a second function;

Figure 7 shows the API functions provided by PD_API;

Figure 8 shows the user-defined IOCTL code specified by IRP_MJ_DEVICE_CONTROL;

FIG. 9 is a flowchart illustrating a process performed using a first function;

10 and 11 are flowcharts illustrating processes performed using the first function;

Figure 12 shows the API functions provided by PD_API;

Figure 13 shows the user-defined IOCTL code specified by IRP_MJ_DEVICE_CONTROL;

Figure 14 shows a flowchart of a process performed using the second function;

15 and 16 are flowcharts illustrating processes performed using the second function;

FIG. 17 shows a block diagram of a structural example of a PD filter performing a third function;

FIG. 18 is a flowchart showing a process performed using the third function;

FIG. 19 is a block diagram showing a structural example of a PD filter performing a cache ON/OFF function;

Figure 20 shows the API functions provided by PD_API;

Figure 21 shows user-defined IOCTL codes specified by IRP_MJ_DEVICE_CONTROL;

Fig. 22 is a flow chart showing the execution process using the cache ON/OFF function;

Fig. 23 is a flow chart showing the execution process using the cache ON/OFF function;

The block diagram of Fig. 24 has shown the structural example of the PD filter that is used by combining one of first and second function and cache memory ON/OFF function;

25 is a block diagram showing a configuration example of a PD filter used by combining the third function and the cache ON/OFF function.

Detailed ways

The present invention is described below through preferred embodiments in conjunction with the accompanying drawings.

The information processing system according to the embodiment of the present invention shown in FIG. 1 includes a personal computer (PC) 1 and a drive 2 .

An operating system (OS) and applications (programs) are stored in the PC 1, and various types of processes are executed by executing the applications under the control of the OS.

Driver 2, the PD driver described above, is connected to PC 1 via 1394 cable 4. The optical disc 3, ie, PD, can be mounted to or removed from the drive 2 so that the drive 2 can communicate with the PC 1 using the Institute of Electrical and Electronics Engineers (IEEE) 1394 standard to read or write data such as AV data from the optical disc 3.

The drive 2 is not necessarily a PD drive and the optical disc 3 is not necessarily a PD. In addition, the PC 1 and the drive 2 can communicate with each other according to standards other than the IEEE 1394 standard.

Fig. 2 shows an example of PC 1 hardware structure.

The PC 1 has a built-in CPU 12. The input/output interface 20 is connected to the CPU 12 through the bus 11. The CPU 12 executes a program stored in a read only memory (ROM) 13 in response to an instruction input by a user through the input/output interface 20 operating the input unit 17 including a keyboard, a mouse, a microphone, and the like. The CPU 12 also executes programs stored in the hard disk 15, programs sent from satellites or networks and received through the communication unit 18 and inserted into the hard disk 15, and programs read from the recording medium 21 on the drive 19 and inserted into the hard disk 15. programs and programs loaded into random access memory (RAM) 14. The CPU 12 then executes the processes shown according to the flow or structure of the block diagram, which will be discussed below. Next, the CPU 12 outputs the processing result from the output unit 16 including a liquid crystal display (LCD) or a speaker through the input/output interface 20. Alternatively, the CPU 12 transmits the processing result from the communication unit 18 through the input/output interface 20 or records it to the hard disk 15.

In the PC 1, an IEEE 1394 interface (I/F) 22 that performs communication in compliance with the IEEE 1394 standard is connected to the input/output interface 20. The drive 2 is connected to the IEEE 1394 interface 22 via a 1394 cable 4 . The CPU 12 accesses the drive 2 through the bus 11, the input/output interface 20, the IEEE 1394 interface 22, and the 1394 cable 4 to read data from or write data to the optical disc 3 set in the drive 2.

The CPU 12 executes an OS and various application programs that can be stored in advance on a recording medium such as a hard disk 15 built in the PC 1 or a ROM 13 or the like.

Alternatively, the program may be temporarily or permanently stored (recorded) on a removable recording medium 21 such as a floppy disk, a compact read-only memory (CD-ROM), a magneto-optical (MO) disk, a digital video disk (DVD), or a magnetic disk. superior. The removable recording medium 21 may also be referred to as "packaged software".

As described above, the program can be installed on the PC 1 from the above-mentioned removable recording medium 21. Alternatively, the program may be wired or wirelessly transferred from the download site to the PC 1 via a digital broadcast satellite, such as via a local area network (LAN) or the Internet. In this case, the PC 1 receives the program through the communication unit 18 and installs it on the built-in hard disk 15.

FIG. 3 illustrates programs executed by the CPU 12 shown in FIG. 2.

For example, OS 30 and application program 31 are installed on the hard disk 15 shown in Figure 2 through 33 at least. When the PC 1 is powered on, the CPU 12 loads the OS 30 from the hard disk 15 onto the RAM 14 and executes it. In response to a request to start the application program 31, 32, or 33 by operating the input unit 17, the CPU 12 loads the corresponding application program 31, 32, or 33 from the hard disk 15 onto the RAM 14, and executes it under the control of the OS 30.

Subsequently, in response to a request from the application program 31, 32 or 33 to access the optical disc 3 set in the drive 2, the OS 30 processes the access request. In the drive 2, data is recorded on the optical disc 3 based on an access request from the application program 31, 32 or 33. Alternatively, in the drive 2, data can be played from the optical disc 3 based on an access request from the application 31, 32 or 33, and the data can be transferred through the OS 30 to the application 31, 32 or 33 that made the access request.

The number of application programs installed on the hard disk 15 shown in FIG. 2 is not limited to three, and can be more or less.

Assume now that, among the three application programs 31, 32, and 33 installed in the hard disk 15, the application program 33 reads AV data from an external source, and edits, records, and plays the AV data. Therefore, the application program 33 may also be called "AV application program 33".

The AV application program 33 calls PD_API (PD_API.DLL) 41, which is a dynamic link library (DLL), and generates a request for accessing the optical disc 3 by the PD_API 41. PD_API 41 is a DLL used to provide a unique application program interface (API), which is discussed later in relation to access to disc 3.

，Linux，或微软公司的

也可以使用其它的OS。在该实施例中，可以使用例如

NT，2000，或

XP的

NT OS来作为OS 30。As for OS 30, you can use

, Linux, or Microsoft's

Other OS can also be used. In this example, one can use for example

NT, 2000, or

xp

NT OS comes as OS 30.

NT OS，更具体地，是OS 30中涉及访问驱动器2中的光盘3的部分。FIG. 4 illustrates an example of the structure of the OS 30, namely

The NT OS, more specifically, is the part of the OS 30 involved in accessing the optical disc 3 in the drive 2 .

In FIG. 4, a layer structure of a device driver of the OS 30 involving application programs 31 to 33 is shown.

can be a The OS 30 of the NT OS executes individual services through subsystems based on microkernel technology and object-oriented technology.

The Win32 subsystem 51, one of the subsystems, provides various application program interface (API) functions to the application programs 31 to 33, and performs processing such as memory management, process management, and drawing.

More specifically, when an API function involving input/output (I/O) is called from an application program 31, 32, or 33, the Win32 subsystem 51 outputs the I/O corresponding to the API function to the NT I/O manager 52. ask.

The API functions provided by the Win32 subsystem 51 include a function CreateFile() for creating a file, a function ReadFile() for reading a file (data recorded in a file), a function WriteFile for writing a file (data) () and the function DeviceIoControl() used to execute other processes.

The NT I/O manager 52 provides services for delivering I/O request packets (IRPs) to layered device drivers.

An IRP is a packet containing information about a process requesting a device driver. The IRP includes a code that classifies the content of the request, IRP_MJ_READ for a request to read data (file), IRP_MJ_WRITE for a request to write (record) data, IRP_MJ_CREATE for a request to create a file, and IRP_MJ_DEVICE_CONTROL for a request to execute other types of processes. In the IRP_MJ_DEVICE_CONTROL IRP, the I/O control (IOCTL) is specified by a user-defined subcode.

For example, NT I/O manager 52 converts the I/O request based on CreatFile () from Win32 subsystem 51 into IRP_MJ_CREATE IRP. Convert ReadFile() and WriteFile() to IRP_MJ_READ IRP and IRP_MJ_WRITE IRP, respectively, and DeviceIoControl() to IRP_MJ_DEVICE_CONTROL IRP.

NT OS中，IRP在存储类的驱动器或更高的层中处理。exist

In NT OS, IRPs are handled in storage-class drivers or higher.

In Fig. 4, there are three layers corresponding to the storage class driver layer or higher, that is, the storage type driver PD memory 55, the PD_FS54 which is one layer higher than the storage class driver and is a file system driver, and one layer higher than the file system driver. Layer's device driver for the PD filter 53 as a file system filter driver.

Thus, in this embodiment, NT I/O Manager 52 provides services for passing IRPs to PD Filter 53, PD_FS 54 and PD Storage 55.

More specifically, the NT I/O manager 52 converts the I/O request from the Win32 subsystem 51 into a corresponding IRP, and outputs the IRP to the PD filter 53, for example. Next, the PD filter 53 outputs a request to the NT I/O manager in response to the IRP from the NT I/O manager 52. Then, the NT I/O manager 52 converts the request from the PD filter 53 into a corresponding IRP, and outputs it to the PD_FS 54. Subsequently, the PD_FS 54 outputs a request to the NT I/O manager in response to the IRP from the NT I/O manager 52. The NT I/O manager 52 then converts the request from the PD_FS 54 into a corresponding IRP and outputs it to the PD memory 55.

PD filter 53 is a file system filter for drive 2, and drive 2 may be a higher PD driver than PD_FS 54. The PD filter 53 filters the file system request including the file system provided by the application program 31 to 33 and other requests through the Win32 subsystem 51 and the NT I/O manager 52, and passes the filtered result and the specific request through NT I/O Manager 52 sends to PD_FS 54.

The PD filter 53 includes a filter core 53A for executing the main process of the PD filter 53 , such as filtering requests from the applications 31 to 33 . The PD filter 53 filters the request according to the information set (stored) in the register 58, wherein the register 58 is register.

The PD_FS 54 for the drive 2 is a file system driver that manages files that have been recorded or will be recorded on the optical disc 3 (PD) set in the drive 2. That is, the PD_FS 54 outputs a read or write request from the PD filter 53 to the PD memory 55 through the NT I/O manager 52 based on the file system representing information for managing data (files) recorded on the optical disc 3 .

Generally, the file system driver has a cache function for caching the file stream (data recorded or to be recorded on the file) and the meta information of the file. By using this caching function, cached file streams and meta information can be quickly fetched without physically accessing the optical disc 3 .

NT OS中，NT高速缓存管理器59具有一个高速缓存功能，同时PD_FS 54通过使用该NT高速缓存管理器59而提供高速缓存功能。exist

In NT OS, the NT cache manager 59 has a cache function, while the PD_FS 54 provides the cache function by using the NT cache manager 59 .

PD_FS 54 has a FS core 54A, which is used to execute the main process of PD_FS 54.

The PD storage 55 is a storage type driver, which is a real device driver for the driver 2, and sends an IRP from the device driver PD_FS 54 higher than the layer of the PD storage 55 through the NT I/O manager 52. The request is converted to Small Computer System Interface (SCSI) code and output to a Serial Bus Protocol (SBP) 2 driver 56 .

The reason for converting the IPR in the PD memory 55 to the SCSI code is that the SCSI code has the greatest compatibility with the SBP2 processed in the driver 56 of the SBP2.

The SBP2 driver 56 converts the SCSI code from the memory 55 into SBP2 data compatible with the SBP2 standard, and supplies the SBP2 data to the 1394 driver 57 .

In this embodiment, SBP2 is used for a protocol capable of handling a file system for performing communications compatible with the IEEE 1394 standard controlled by the 1394 bus driver 57. However, other protocols may be used in addition to SBP2.

The IEEE bus driver 57 controls the IEEE 1394 interface 22 ( FIG. 2 ) to send SBP2 data from the SBP2 driver 56 to the drive 2 or to receive data read from the optical disc 3 and send it from the drive 2.

In this embodiment, communication compatible with the IEEE 1394 standard is performed between the PC 1 and the drive 2. However, communication other than IEEE 1394 communication may also be performed, and in this case, a bus driver corresponding to communication between the PC 1 and the driver 2 is used in addition to the 1394 bus driver 57.

In FIG. 4, the PD_API 41 used by the AV application 33 provides a unique API function. More specifically, when the only API function is called by the AV application 33, the PD_API 41 uses the corresponding API function DeviceIoControl() provided by the Win32 subsystem 51 to provide the PD filter 53 with user The IRP_MJ_DEVICE_CONTROL IRP for the defined IOCTL. Thus, the PD_API 41 controls the only function of the PD filter 53, that is, the function indicated by the IOCTL.

The AV application 33 containing the PD_API 41 is sold by being recorded on the removable recording medium 21 ( FIG. 2 ) together with the PD filter 53, PD_FS 54, and PD storage 55 required to use the drive 2. The removable recording medium 21 on which the AV application 33, the PD filter 53, the PD_FS 54, and the PD storage 55 are recorded can be sold as a single unit. Alternatively, the removable recording medium 21 may be sold as an accessory of the drive 2 contained in the drive 2 .

In Fig. 4, applications 31 to 33 and Win32 subsystem 51 all work in user mode, while NT I/O manager 52, PD filter 53, PD_FS 54, PD memory 55, SBP driver 56 and 1394 bus driver 57 are working in kernel mode.

NT OS的NT I/O管理器52不仅能发送IRP，而且还能发送FastIO给文件系统过滤器驱动器或文件系统驱动器来请求驱动器执行进程。In FIG. 4, NT I/O manager 52 sends an IRP to PD filter 53 as a file system filter driver and PD_FS 54 as a file system driver to request the file system filter driver or file system driver to perform specific process.

The NT I/O manager 52 of the NT OS can not only send IRPs, but also send FastIOs to the file system filter driver or the file system driver to request the driver to execute a process.

That is, the NT I/O manager 52 also provides for sending FastIO to a file system filter driver or file system driver to request it to execute a process.

NT OS的文件系统过滤器驱动器和文件系统驱动器通常同时支持IRP和FastIO。therefore,

NT OS file system filter drivers and file system drivers usually support both IRP and FastIO.

According to FastIO, files can be read directly from or written to the NT Cache Manager 59.

It is assumed that in this embodiment, IRP is used between IRP and FastIO. However, FastIO can also be implemented with the functions described below.

Now according to the flow chart of Fig. 5, all processes are all passed through the PD filter 53, PD_FS54, PD memory in the OS 30 in response to the access request from the application program 31, 32, or 33 as shown in Fig. 4 55, SBP2 driver 56, and 1394 bus driver 57 to execute.

In the following description and FIGS. 5 to 25, explanations and descriptions of the Win32 subsystem 51 and the NT I/O manager 52 are omitted unless necessary.

When an application 31, 32, or 33 calls a function representing a request to access the optical disc 3, the corresponding request is provided from the Win32 subsystem 51 to the NT I/O manager 52. Next, the NT I/O manager 52 supplies the IRP corresponding to the request from the Win32 subsystem 51 to the PD filter 53.

In step S1, the PD filter 53 receives the IRP from the NT I/O manager 52. Next, in step S2, the PD filter 53 filters the IRP received from the NT I/O manager 52. In step S3, the PD filter 53 supplies the IRP from the NT I/O manager 52 to a queue (not shown in FIG. 4 ) and stores it therein. Subsequently, the PD filter 53 reads the IRP stored in the queue and provides it to the PD_FS 54 through the NT I/O manager 52.

In step S4, the PD_FS 54 executes the caching process required for using the caching function of the NT cache manager 59 in the data requested by the IRP from the PD filter 53. In step S5, the PD_FS 54 determines whether the data requested by the IRP from the PD filter 53 is already cached in the NT cache manager 59.

If it is determined in step S5 that the data requested by the IRP is cached in the NT cache manager 59, the process goes to step S6. In step S6, PD_FS 54 has received the requested data from the IRP in the NT cache manager 59, and through the PD filter 53 and the Win32 subsystem 51, the application that has called the API function corresponding to the IRP The response from the IR of program 31, 32, or 33 is returned.

If it is determined in step S5 that the data requested by the IRP is not cached in the NT cache manager 59, the process goes to step S7. In step S7, the PD_FS 54 supplies the IRP from the PD filter 53 to the PD storage 55 through the NT I/O manager 52.

In step S8, the PD memory 55 converts the IRP from the PD_FS 54 into corresponding SCSI encoding and provides it to the SBP2 driver 56.

In step S9 , the SBP2 driver 56 converts the SCSI code into SBP2 data and supplies it to the 1394 bus driver 57 .

In step S10, the 1394 bus driver 57 controls the IEEE 1394 interface 22 (FIG. 2) to send the SBP2 data from the SBP2 driver 56 to the driver 2.

Next, the 1394 bus driver 57 waits for a response to the SBP2 data sent from the driver 2 in step S10. In step S11, 1394 bus driver 57 receives the reply and returns it to the IRP that has been sent through SBP2 driver 56, PD memory 55, PD_FS 54, PD filter 53, and Win32 subsystem 51 in step S1. Application 31, 32, or 33.

In FIG. 4, if one application program accesses the optical disc 3 before another application program (for example, the application program 33) among the application programs 31 to 33, an inquiry is also required when the application program 33 accesses the optical disc 3. The application 33 must also wait for access to the disc 3 .

In FIG. 4 , the application program 33 is an AV application program capable of writing (recording) AV data to the optical disc 3 or reading (playing) AV data from the optical disc 3 .

If the drive 2 is designated to read or write AV data in real time in response to access only from the AV application 33, access to the optical disc 3 by the application 31 or 32 is required for inquiry. At the same time, the AV application 33 must also wait for access to the optical disc 3 . As a result, it becomes difficult for the AV application 33 to read or write AV data in real time.

Therefore, the PD filter 53 has at least one of the following three functions, and can read AV data from or write AV data to the optical disc 3 in real time and reliably.

In the first function, the PD filter 53 sets a specific priority of an IRP corresponding to an access request to the optical disc 3 from the application 31, 32, or 33 and stores the IRP with its priority in a queue. Next, the PD filter 53 processes the IRP stored in the queue according to the priority set by the IRP. Due to such a structure, the PD filter 53 can pre-process an IRP indicating an access request from the AV application 33, thereby being able to ensure that the AV application 33 reads and writes AV data in real time.

FIG. 6 illustrates a structural example of the PD filter 53 that realizes the first function described above. In FIG. 6, application programs 31 to 33 are also shown.

NT OS的OS 30，以所谓的“进程”为单位执行程序。为了执行进程，要给该进程指定至少一个线程，并且进程是在线程中执行的。for

The OS 30 of the NT OS executes programs in units of so-called "processes". In order to execute a process, at least one thread must be assigned to the process, and the process is executed in the thread.

In FIG. 6 , the application program 31 includes two processes 71 and 72 . Process 71 is executed by two threads 71A and 71B, while process 72 is executed by one thread 72A.

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

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

The calls of the API functions to the Win32 subsystem 51 are executed in units of threads. Therefore, in the structure shown in FIG. 6, the API function can be called in each of the threads 71A, 71B, 72A, 73A, 73B, 74A, 74B, and 75A.

Calling an API function from a thread means calling the API function from a process executed by the thread.

When the API function is called in one of the threads 71A to 75A, the corresponding IRP is supplied from the NT I/O manager 52 to the PD filter 53.

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

NT OS的OS 30，具有一个设置进程和线程的优先级并根据优先级执行进程和线程的标准的优先级函数。根据该优先级函数，PC 1的资源，例如，CPU 12，RAM 14，等，可以预先指定给由OS 30所设置的具有高优先级的进程和线程。for

OS 30 of the NT OS has a standard priority function that sets the priority of processes and threads and executes processes and threads according to the priority. According to this priority function, the resources of PC 1, such as CPU 12, RAM 14, etc., can be pre-assigned to processes and threads with high priority set by OS 30.

Therefore, by using the priority function, the processes 74 and 75 of the AV application 33 can be set to have higher priority than the processes 71 and 72 of the application 31 and the process 73 of the application 32, so that the AV application 33 can Disc 3 is accessed before applications 31 and 32 .

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

Therefore, if a higher priority is set to the process of the AV application program 33 by using the priority function, the process of other important services provided by the OS 30 must wait for a long time before using the CPU 12 or the RAM 14. This results in the interruption of the execution of important services, or worse, the hang of PC 1.

Thus, in the PD filter 53, the filter core 53A sets the IRP priority independent of the priority of the IRP provided by the NT I/O manager 52 as set by the standard priority function.

The priority of the IPR is only the priority for accessing the disc 3 . Therefore, when a higher priority is set for the AV application program 33, what this IRP priority affects is only related to the process of accessing the optical disc 3, and does not limit the process of other services provided by the OS 30, such as the CPU 12 or RAM 14 usage. Depending on the priority of the IRP, interruption of important services provided by the OS 30 or suspension of the PC 1 can be prevented.

The PD filter 53 sets the IRP priority of the IRP from the NT I/O manager 52, and provides the IRP to the queue 81A or 81B and stores it there. That is, the queue 81A or 81B stores therein the IRP together with the priority of the IRP provided by the filter core 53A.

In the structure shown in FIG. 6 , two queues 81A or 81B are provided, assuming that two volumes exist in the drive 2 . That is, queues 81A and 81B are associated with two corresponding volumes. PD filter 53 provides IRPs in response to volumes associated with 81A to queue 81 and IRPs in response to volumes associated with 81B to queue 81B. The queues 81A and 81B may also be simply referred to as "queue 81" hereinafter unless it is necessary to distinguish them.

The PD filter 53 processes the IRPs stored in the queue 81 according to the priority set to the IRPs. That is, the PD filter 53 reads an IRP with a high priority from the queue 81 in advance, and provides it to the PD_FS 54 through the NTI/O manager 52.

A thread (the same as that applied to the second function and the third function) for executing the process of the first function is formed at the file system filter driver layer of the PD filter 53 . A queue 81 for storing IRPs is also formed by the filter driver layer of the file system.

In order to process the IRP from the AV application 33 ahead of the IRPs from the applications 31 and 32 by using the PD filter 53 in advance, the PD filter 53 sets the highest IRP for the IRP with the process ID registered in the PD filter 53 priority, and set the lowest IRP priority for IRPs that do not have a process ID registered in PD filter 53.

That is, the OS 30 manages each process by assigning a unique process ID to the process, and an IRP from each process (an IRP associated with an API function called by each process) has a unique process ID. Subsequently, if the process ID provided for an IRP in a particular process received from NT I/O manager 52 matches the process ID registered in PD filter 53, then PD filter 53 sets Highest IRP priority. If the process ID for the received IRP is different from the process ID registered in the PD filter 53 (or if there is no process ID registered in the PD filter 53), then the PD filter 53 sets the lowest IRP for the IRP priority.

The data representing the priority of the IRP can be, for example, 5 bits. In this case, the highest IRP priority is 31 and the lowest IRP priority is 0.

In order to use the first function of the PD filter 53, when it is loaded, use (load) the PD_API 41 in the AV application 33 to request the process ID of the PD filter 53 register process 75, when loading the PD_API 41, pass The API function DeviceIoControl() provided by the Win32 subsystem 51 is used. That is, when the AV application 33 starts loading the PD_API 41 by the process 75 of the AV application 33, the PD_API 41 calls the API function DeviceIoControl() that requests the PD filter 53 to register the process ID assigned to the process 75.

When the process 75 is completed, the PD_API 41 calls the API function DeviceIoControl() that requests the PD filter 53 to delete the process ID assigned to the process 75.

Therefore, as long as there is a process 75 of PD_API 41, the highest IRP priority is set in the PD filter 53 for the IRP of the process 75 (the IRP associated with the API function provided by the Win32 subsystem 51) and passed through the process 75 Call (PD_API 41).

FIG. 7 shows an API function for the PD_API 41 to control the PD filter 53 when the PD filter 53 executes a process using the first function. The API functions shown in FIG. 7 are provided to the AV application 33.

In FIG. 7, the API functions that allow the PD_API 41 to control the PD filter 53 include two functions, namely, PdGetPriority() and PdSetPriority(). In these two API functions PdGetPriority() and PdSetPriority(), process ID and IRP priority are used as parameters.

When the API function PdGetPriority( ) is called by specifying a process ID as a parameter, the IRP priority set by the PD filter 53 for responding with the specified process ID is returned together with the parameter. In the API function PdGetPriority (), when the capture of the IRP priority set by the PD filter 53 for the process with the specific process ID is successful, 1 is returned as a return value, and when the capture of the IRP priority fails , returns 0 as the return value.

According to the API function PdGetPriority( ), the IRP priority set by the PD filter 53 for the IRP from a specific process can be determined.

When the API function PdSetPriority() is called by designating a process ID and an IRP priority as parameters, the IRP priority set by the PD filter 53 for a process having a specific process ID as a parameter becomes used as a parameter IRP priority. In the API function PdSetPriority(), when the IRP priority set by the PD filter 53 is successfully changed, 1 is returned as a return value, and when the IRP priority is not successfully changed, 0 is returned.

According to the API function PdSetPriority(), it can be set by the PD filter 53 as an IRP from a process with a process ID registered in the PD filter 53 or from a process with a process ID not registered in the PD filter 53. The IRP priority set by the IRP.

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

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

As discussed above, in order to use the first function of the PD filter 53, the PD_API 41 calls the API function DeviceIoControl() representing a request to register a process ID and the API function DeviceIoControl() representing a request to delete a process ID, and if necessary, The API function DeviceIoControl( ) represents a request to transmit the IRP priority set by the PD filter 53 and the API function DeviceIoControl( ) represents a request to change the IRP priority set by the PD filter 53 .

When calling the API function DeviceIoControl (), the Win32 subsystem 51 sends a request to the NT I/O manager 52 in response to the API function DeviceIoControl (). The NT I/O manager 52 then converts the request into an IRP_MJ_DEVICE_CONTROL IRP and provides it to the PD filter 53.

As mentioned above, in the IRP_MJ_DEVICE_CONTROL IRP, the IOCTL defined by the user is indicated by the subcode.

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

In Figure 8, four IOCTLs (subcodes), namely IOCTL_PD_SET_PROCESSID, IOCTL_PD_DELETE_PROCESSID, IOCTL_PD_SET_PRIORITY, and IOCTL_PD_GET_PRIORITY, can be used as user-defined IOCTLs.

IOCTL_PD_SET_PROCESSID is an IOCTL that is a subcode of IRP_MJ_DEVICE_CONTROL of the API function DeviceIoControl( ) in response to a request indicating a register process ID. The API function DeviceIoControl() representing the request to register the process ID uses the process ID to register as a parameter, and IOCTL_PD_SET_PROCESSID is the IOCTL for requesting the PD filter 53 to register the process ID in the PD filter 53.

IOCTL_PD_DELETE_PROCESSID is an IOCTL that is a subcode of IRP_MJ_DEVICE_CONTROL of the API function DeviceIoControl( ) in response to a request indicating a process ID to be deleted. The API function DeviceIoControl( ) representing a request to delete a process ID uses the process ID as a parameter to delete, and IOCTL_PD_DELETE_PROCESSID is an IOCTL for a request to request the PD filter 53 to delete the process ID from the PD filter 53 .

IOCTL_PD_SET_PRI ORITY is an IOCTL that is a subcode of IRP_MJ_DEVICE_CONTROLIRP of the API function DeviceIoControl( ) in response to a request representing a change of the IRP priority set by the PD filter 53. According to this IOCTL, the IRP priority that will be set for the IRP with the process ID becomes the IRP priority that is also the parameter of the API function PdSetPriority(), where the previous IRP priority is used as the The response of is indicative of the parameter of the API function PdSetPriority() of the API function DeviceIoControl() of the request to change the IRP priority set by the PD filter 53 .

IOCTL_PD_GET_PRIORITY is an IOCTL that is a subcode of IRP_MJ_DEVICE_CONTROLIRP of the API function DeviceIoControl( ) in response to a request indicating acquisition of the process ID set by the PD filter 53 . According to this IOCTL, the request has the IRP priority set by the process ID used as the response shown in FIG. The parameter of the API function PdSetPriority().

A user-defined IOCTL that is a subcode of the IRP_MJ_DEVICE_CONTROL IRP is sent from the subsystem 51 to the NT I/O manager 52 by using the API function DeviceIoControl() provided by the Win32 subsystem 51, and passed through the NT I/O manager 52 Use it as a subcode of the IRP_MJ_DEVICE_CONTROL IRP.

Now in conjunction with the flowchart in FIG. 9, describe when the PD filter 53 performs the first function, the AV application program 33 shown in FIG. 6, the PD_API 41, and the entire process performed by the PD filter 53.

When starting the AV application program 33, in step S21, the AV application program 33 loads the PD_API 41 through the process 75. Then, in step S31, PD_API 41 API function DeviceIoControl (), this function call represents the request of registering the process ID of the process 75 of PD_API 41, so that the IOCTL_PD_SET_PROCESSID of the IOCTL with the request of the process ID of the register process 75 will be IRP_MJ_DEVICE_CONTROL is supplied from the NT I/O manager 52 to the PD filter 53.

In step S41, the PD filter 53 receives the IRP from the NT I/O manager 52 and registers the process ID of the process 75 of the PD_API 41 according to the IOCTL_PD_SET_PROCESSID of the IRP.

Therefore, subsequently, unless the process ID of process 75 of PD_API 41 is deleted, the highest IRP priority is set for IRPs from process 75, and the lowest IRP priority is set for IRPs from other processes. Therefore, in PD filter 53, IRPs from process 75 can be processed preferentially.

More specifically, if in step S22, for example AV application program 33 transfers the API function ReadFile () that reads the file request as the request of accessing optical disc 3, then in step S32, PD_API 41 receives the request to API function ReadFile () transfer.

In step S33, in order to respond to the call from the API function ReadFile () of AV application program 33, PD_API 41 calls the same API function ReadFile () that Win32 subsystem 51 provides, then, represents the IRP_MJ_READ IRP of reading file request is supplied from the NT I/O manager 52 to the PD filter 53.

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

More specifically, the IRP_MJ_READ IRP received by the PD filter 53 in step S42 is the IRP of the process 75 from the PD_API 41. The process ID of the process 75 is registered in the PD filter 53 in step S41. Therefore, the IRP_MJ_READ IRP received by the PD filter 53 from the process 75 in step S42 has the highest IRP priority.

As a result, in the PD filter 53, the IRP_MJ_READ IRP in the process 75 from the PD_API 41 will be processed immediately as long as there are no other IRPs with the highest IRP priority.

In step S43, the PD filter 53 preferentially provides the IRP_MJ_READ IRP from the process 75 of the PD_API 41 to the PD_FS 54.

Next, when the AV application 33 ends, in step S23, the AV application 33 requests the process 75 of the PD_API 41 to unload the PD_API 41.

In order to respond to this request, in step S34, PD_API 41 calls the API function DeviceIoControl () that represents the process ID request of deleting process 75 so as to have the IRP_DEVICE_CONTROL IRP of IOCTL_PD_DELETE_PROCESSID designated as the IOCTL that represents the process ID request of deleting process 75 from NT I/ O manager 52 supplies to PD filter 53 .

In step S44, the PD filter 53 receives the IRP from the NT I/O manager 52 and deletes the process ID of the process 75 of the PD_API 41 according to the IOCTL_PD_DELETE_PROCESSID of the IRP.

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

The process by which the PD filter 53 shown in FIG. 6 performs the first function will be discussed below with reference to FIGS. 10 and 11 .

Firstly, the flow chart of FIG. 10 is used to discuss the period from when the IRP is received by the PD filter 53 having the first function shown in FIG. process.

In response to a call to an API function representing the execution of a process involving I/O by one of the processes 71 to 75 in the application programs 31 to 33 on the driver 2, the Win32 subsystem 51 outputs a request to the NT I/O manager 52 , and the NT I/O manager 52 supplies the IRP corresponding to the API function to the PD filter 53 in response to a request output from the Win32 subsystem 51.

In the PD filter 53, in step S51, the filter core 53A receives an IRP requested by a process that has called an API function from the NT I/O manager 52. In step S52, filter core 53A determines whether the IRP is an IRP_MJ_DEVICE_CONTROL IRP with IOCTL_PD_SET_PROCESSID (FIG. 8) specified as the IOCTL.

If it is determined in step S52 that the IRP received by the filter core 53A in step S51 is IRP_MJ_DEVICE_CONTROLIRP with IOCTL_PD_SET_PROCESSID specified as the IOCTL, the process jumps to step S53. In step S53, the filter core 53A registers (stores) the process ID contained in the IRP, that is, the process ID of the process which has called the API function corresponding to the IRP, and the process returns to step S51.

That is, the IRP with IOCTL_PD_SET_PROCESSID designated as IOCTL contains the process ID of the process that has called the API function corresponding to the IRP, and the filter core 53A registers the process ID. The process ID registered by the filter core 53A is also referred to as "registered process ID" hereinafter.

If it is determined in step S52 that the IRP requested by the process is not the IRP with the IOCTL_PD_SET_PROCESSID designated as the IOCTL, then the process goes to step S54 to determine whether the IRP is the IRP_MJ_DEVICE_CONTROL IRP with the IOCTL_PD_DELETE_PROCESSID (FIG. 8) specified as the IOCTL.

If it is determined in step S54 that the IRP is an IRP with IOCTL_PD_DELETE_PROCESSID designated as the IOCTL, the process goes to step S55. In step S55, the filter core 53A deletes the registered process ID, and the process returns to step S51.

If it is determined in step S54 that the IRP is not an IRP having IOCTL_PD_DELETE_PROCESSID specified as an IOCTL, the process goes to step S56 to determine whether the IRP is an IRP representing a request to access the optical disc 3 .

If it is determined in step S56 that the IRP requested by the process is not an IRP representing an access request, that is, the IRP is an IRP_MJ_DEVICE_CONTROL IRP having IOCTL_PD_SET_PRIORITY (FIG. 8) designated as an IOCTL representing a request to change the IRP priority set by the PD filter 53. Or there is an IRP_MJ_DEVICE_CONTROL IRP designated as IOCTL_PD_GET_PRIORITY ( FIG. 8 ) of the IOCTL representing the acquisition of the IRP priority set by the PD filter 53, and the process goes to step S57. In step S57, the filter core 53A executes the process based on the IRP, and returns the result of the response process to the process that has called the API function by the NT I/O manager 52 and the Win32 subsystem 51. Then, the process returns to step S51.

If the IRP requested by the process is the IRP with the IOCTL_PD_SET_PRIORITY specified as the IOCTL, then in step S57, the filter core 53A will change the IRP priority set for the IRP requested by the process with the process ID specified in the IOCTL_PD_SET_PRIORITY For the IRP priority also specified in IOCTL_PD_SET_PRIORITY. If the IRP requested by the process is the IRP with the IOCTL_PD_GET_PRIORITY specified as the IOCTL, in step S57, the filter core 53A returns the IRP priority set for the IRP requested by the process having the process ID specified in the IOCTL_PD_GET_PRIORITY as a response .

If in step S56, determine that the IRP requested by the process is the IRP representing the access request, that is, the IRP represents the IRP_MJ_READ IRP of the read file request or the IRP_MJ_WRITE IRP of the write file request, then the process proceeds to step S58. In step S58, the filter core 53A determines whether the process ID included in the IRP requested by the process, that is, the process ID of the process that has called the API function corresponding to the IRP, coincides with the registered process ID.

If it is determined in step S58 that the process ID included in the IRP of the process request does not coincide with the registered process ID, the process goes to step S59. In step S59, the filter core 53A sets the lowest IRP priority for the IRP requested by the process and the process goes to step S61.

If it is determined in step S58 that the process ID contained in the IRP of the process request coincides with the registered process ID, the process goes to step S60. In step S60, the filter core 53A sets the highest IRP priority for the IRP requested by the process and the process goes to step S61.

In step S61, the filter core 53A outputs the IRP having the same priority as the IRP set in step S59 or step S60 to the queue 81 and stores it therein, and waits for another IRP. The process then returns to step S51.

In FIG. 10, if the process ID included in the IRP requested by the process is different from the registered process ID, the lowest IRP priority is set to the IRP. If the process ID contained in the IRP is the same as the registered process ID, the IRP is given the highest IRP priority. However, other levels of IRP priority may also be set for IRPs.

Setting the IRP priority to an IRP with a specific process ID, for example, an IRP with a process ID identical to a registered process ID can be specified by the API function PdSetPriority() shown in FIG. 7 .

For the registered process ID, a plurality of process IDs may be registered. In this case, a unique IRP priority can be assigned to each registered ID, and an IRP with a process ID that matches a registered process ID can be assigned the IRP priority assigned to a registered process ID .

The process on the IRP stored in the queue 81 generated by the PD filter 53 having the first function shown in FIG. describe.

In the PD filter 53, the filter core 53A searches for a highest IRP priority among the IRPs stored in the queue 81 in step S71.

In step S72, the filter core 53A processes the IRP with the highest IRP priority found in step S71, and the process returns to step S71. More specifically, in step S72, the filter core 53A reads the IRP with the highest IRP priority from the queue 81 in advance and outputs it to the PD_FS 54 through the NT I/O manager 52.

If a plurality of IRPs with the highest IRP priority are found in step S71, the filter core 53A processes the plurality of IRPs according to the standard priority function of the OS 30 or the time the IRPs are stored in the queue 81. That is, the filter core 53A pre-reads the IRPs from the process with the highest priority from the queue 81 and outputs them to the PD_FS 54 based on a standard priority function or the oldest stored IRP.

As discussed above, in the PD filter 53, IRPs are set with an IRP priority different from the standard priority function of the OS 30. More specifically, for an IRP requested by a process with a process ID that matches the registered process ID, set the highest IRP priority for that IRP, while for an IRP requested by a process with a process ID that is inconsistent with the registered process ID The requested IRP for which the lowest IRP priority is set.

Next, the PD filter 53 stores the IRPs with the provided IRP priorities in the queue 81, and processes the IRPs stored in the queue 81 according to the IRP priorities.

In the AV application 33, when the PD_API 41 is loaded by the process 75, the PD_API 41 requests the PD filter 53 to register the process ID of the process 75, and the PD filter 53 registers the process ID of the process 75 of the PD_API 41.

Next, the AV application program 33 generates a request to access the disc 3 by the process 75 of the PD_API 41.

Therefore, in the PD filter 53 , the IRP indicating the AV application 33's request to access the optical disc 3 is executed prior to the IRPs of the applications 31 and 32 . Thus, the AV application 33 does not have to wait until the execution of the IRP of the application 31 or 32 or the addressing required in the driver 2 caused by the process on the IRP of the application 31 or 32 is completed. As a result, interruption of reading data from or writing data to the optical disc 3 by the AV application program 33 can be avoided, and thus AV data can be recorded to or played back from the optical disc 3 in real time.

In order to record AV data on or play AV data from the optical disc 3 in real time, only an IRP indicating a request for access to the optical disc 3 by the AV application 33 needs to be preprocessed when the AV application 33 records or plays AV data.

In the above-described embodiment, as discussed with reference to FIG. 9 , an IRP representing a request for access to the optical disc 3 by the AV application 33 is preprocessed only when the PD filter 53 loads the PD_API 41.

Therefore, in addition to starting when the AV application 33 starts loading the PD_API 41 and unloading the PD_API 41 when the AV application 33 is completed, the PD_API 41 can also be loaded when the AV application 33 starts recording or playing AV data and is not used during recording or playback. Unloads when the playback operation completes.

The second function of the PD filter 53 for reliably reading and writing AV data in real time will be described below.

More specifically, according to the second function, the PD filter 53 sets a pause flag representing whether the IRP process representing the request for access to the optical disk 3 from the application programs 31 to 33 is allowed or prohibited, IRPs are stored in queue 81. The PD filter 53 then processes the IRPs stored in the queue 81 according to the pause flag. Due to such a structure, the PD filter 53 interrupts the processing of IRPs from applications other than the AV application 33 and only processes IRPs from the application 33 . As a result, the application program 33 can read or write AV data in real time and reliably.

That is, by using the second function, the PD filter 53 enters one of the following two states: an interrupt state in which only a specific IRP is allowed to be processed without processing other IRPs according to the suspend flag, and a running state in which all IRPs can be processed.

For example, the structure of the PD filter 53 having the above-mentioned second function is shown in FIG. 6 .

More specifically, in the PD filter 53 having the second function, in addition to registering the process ID and setting the IRP priority for the IRP, the filter core 53A also sets the pause flag. The filter core 53A also processes the IRPs stored in the queue 81 according to the IRP priority and the pause flag.

In order to use the second function of the PD filter 53, the PD_API 41 used by the AV application 33 provides an API function for setting the PD filter 53 to the AV application 33 in an interrupted state or in a running state.

FIG. 12 illustrates API functions that allow the PD_API 41 to control the PD filter 53 when the PD filter 53 executes a process using the second function. The API functions shown in FIG. 12 are provided to the AV application 33.

In FIG. 12, the API functions for controlling the PD filter 53 described above are omitted.

In FIG. 12, API functions for allowing the PD_API 41 to control the PD filter 53 include two functions, namely, PdPauseOtherAppIrp() and PdRunOtherAppIrp().

According to the API function PdPauseOtherAppIrp(), the PD filter 53 is in a pause state to only process a specific IRP and pause other IRPs. According to the API function PdRunOtherAppIrp(), the PD filter 53 is in the running state to process all IRPs.

The API functions PdPauseOtherAppIrp() and PdRunOtherAppIrp() both take the volume name of a specific volume as a parameter.

By calling the API function PdPauseOtherAppIrp() by specifying the volume name as a parameter, the PD filter 53 is in an interrupt state to process only a specific IRP among IRPs expressing a request to access the volume specified by the volume name as a parameter and to interrupt other IRPs processing.

By calling the API function PdRunOtherAppIrp( ) specifying the volume name as a parameter, the PD filter 53 is in a running state to process all IRPs indicating a request to access the volume specified by the volume name as a parameter.

The PD filter 53 can be set for each volume, that is, each queue associated with the corresponding volume, to be in the interrupted state or the running state. For example, in the PD filter 53, the interrupt status or the running status is set in the queues 81A and 81B.

But for simplicity, the same state, ie interrupted state or running state, can be set for both queues 81A and 81B.

In the API function PdPauseOtherAppIrp(), if the PD filter 53 has been successfully set to the pause state, 1 is returned as the return value, and if the PD filter 53 is not successfully set to the pause state, 0 is returned as the return value. Similarly, in the API function PdRunOtherAppIrp(), if the PD filter 53 has been successfully set to the running state, then 1 is returned as the return value, and if the PD filter 53 is not successfully set to the running state, then 0 is returned as value returned.

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

When the API function PdRunOtherAppIrp() is called, the PD_API 41 calls the API function DeviceIoControl() that makes the PD filter 53 in the running state.

When calling the API function DeviceIoControl (), the Win32 subsystem 51 outputs a request in response to the API function DeviceIoControl () to the NT I/O manager 52, and the NT I/O manager 52 converts the request into an IRP_MJ_DEVICE_CONTROL IRP and converts it Provided to PD filter 53.

As mentioned above, in IRP_MJ_DEVICE_CONTROL, IOCTL is specified as a user-defined subcode.

FIG. 13 illustrates a user-defined IOCTL specified in IRP_MJ_DEVICE_CONTROL when the PD filter 53 executes a process using the second function.

As in FIG. 12, in FIG. 13, the user-defined IOCTL discussed above is not shown.

In FIG. 13, two TOCTL subcodes, namely, IOCTL_PD_PAUSE_OTHERAPPIRP and IOCTL_PD_RUN_OTHERAPPIRP, can be used as user-defined IOCTLs.

IOCTL_PD_RUN_OTHERAPPIRP is the IOCTL of the character code of the IRP_MJ_DEVICE_CONTROL IRP of the API function DeviceIoControl() that responds to the request representing that the PD filter 53 is set to the interrupted state.

IOCTL_PD_PAUSE_OTHERAPPIRP is an IOCTL of a subcode of the IRP_MJ_DEVICE_CONTROL IRP of the API function DeviceIoControl( ) that responds to a request indicating that the PD filter 53 is set in the running state.

The IOCTL defined by the user, i.e. the subcode of the IRP_MJ_DEVICE_CONTROL IRP, is transmitted from the Win32 system 51 to the NT I/O manager 52 by using the API function DeviceIoControl () provided by the Win32 subsystem 51, and is used by the NT I/O manager 52 is designated as the subcode of the IRP_MJ_DEVICE_CONTROL IRP.

The entire process of the AV application 33, the PD_API 41 shown in FIG. 6, and the PD filter 53 when the PD filter 53 executes the second function will now be described with reference to the flowchart of FIG.

In response to a request for recording AV data on or playing AV data from the optical disc 3 generated by the user operating the input unit 17 (FIG. 2), the AV application 33 calls the API function PdPauseOtherAppIrp() in step S91.

In step S101, the PD_API 41 receives a call to the API function PdPauseOtherAppIrp() from the AV application 33. Next, in step S102, the PD_API 41 calls the API function DeviceIoControl() indicating that the PD_API 41 calls the request PD filter 53 to be in the interrupted state in response to the calling of the API function PdPauseOtherAppIrp() so as to have The IRP_MJ_DEVICE_CONTROL IRP with the IOCTL_PD_PAUSE_OTHERAPPIRP of the state is supplied from the NT I/O manager 52 to the PD filter 53 .

In step S111, the PD filter 53 receives the IRP from the NT I/O manager 52 and sets the pause flag to 1 according to the IOCTL_PD_PAUSE_OTHERAPPIRP, thereby enabling the PD filter 53 to operate in an interrupted state.

In the interrupt state, the PD filter 53 interrupts the processing of the IRP requested by all other processes except the process 75 of the PD_API 41 and only processes the requested IRP of the process 75 of the PD_API 41.

If, in step S92, the AV application 33 calls the API function ReadFile( ) representing a request to read a file as a request to access the optical disc 3, then the PD_API 41 receives a call to the API function ReadFile( ) in step S103.

In step S104, in response to the call to the API function ReadFile() from the AV application 33, the PD_API 41 calls the same API function ReadFile() so that the IRP_MJ_READ IRP representing the read file request is provided from the NT I/O manager 52 to PD filter 53.

In step S112, the PD filter 53 receives the IRP_MJ_READ IRP from the NT I/O manager 52. In step S113, the PD filter 53 stores the IRP received in step S112, that is, the IRP requested by the process 75 of the PD_API 41 in the queue 81 (FIG. 6). Next, PD filter 53 reads the IRP from queue 81 and provides it to PD_FS 54.

As mentioned above, the IRP of the process 75 of the AV application 33 is processed immediately.

On the other hand, if the processes 71 to 73 of the application programs 31 and 32 other than the AV application program 33 call the API function ReadFile() representing a read file request as a request to access the optical disc 3 in steps S81 to S83, then The IRP_MJ_READ IRP representing the read file request is provided to the PD filter 53 from the NT I/O manager 52.

In steps S114 to S116 , the PD filter 53 receives an IRP in response to the API function ReadFile( ) called in steps S81 to S83 , and stores the IRP in the queue 81 .

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

Next, in response to the request of the AV application 33 to stop the playback operation of the AV data recorded on the optical disc 3 or to complete the user's operation of the input unit 17, the AV application 33 calls the API function PdRunOtherAppIrp() in step S93.

In step S105, the PD_API 41 receives a call from the AV application 33 to the API function PdRunOtherAppIrp(). Then, in step S106, the PD_API 41 calls the request PD filter 53 to respond to the API function DeviceIoControl () of the calling of the API function PdRunOtherAppIrp (), so that the IOCTL that requests the PD filter 53 to be the running state has an IOCTL designated as the IOCTL IRP_MJ_DEVICE_CONTROLIRP of IOCTL_PD_RUN_OTHERAPPIRP is supplied from NT I/O manager 52 to PD filter 53.

In step S117, the PD filter 53 receives the IRP from the NT I/O manager 52 and resets the suspend flag according to the IOCTL_PD_RUN_OTHERAPPIRP representing the running state being 0, thereby allowing the PD filter 53 to run in the running state.

Next, the PD filter 53 starts (restarts) processing IRPs of processes other than the process 75 of the PD_API 41.

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

Next, in steps S118 to S120, the PD filter 53 reads the IRPs of the processes 71 to 73 stored in the queue 81, and supplies them to the PD_FS 54.

Next, in step S84, when one of the processes 71 to 73 of the application programs 31 to 32 other than the AV application program 33 calls the API function ReadFile() representing a request to read a file as a request to access the optical disc 3, The IRP_MJ_READ IRP representing the read file request is provided to the PD filter 53 from the NT I/O manager 52.

In step S121, the PD filter 53 receives the IRP in response to the API function ReadFile() called by one of the processes 71 to 73 in step S84 and stores its IRP in the queue 81.

In this case, since the PD filter 53 is in the running state, then in step S122, it reads the IRP stored in the queue 81 in step S121 and supplies it to the PD_FS 54.

As described above, when the PD filter 53 is in the interrupt state, it only outputs IRPs from the AV application 33 to the PD_FS 54. When the PD filter 53 changes from the interrupt state to the running state, it also outputs the IRPs of other application programs except the AV application program 33 to the PD_FS 54.

The process performed by the PD filter 53 shown in FIG. 6 will be described below with reference to FIGS. 15 and 16 .

First, the process from the IRP received by the PD filter 53 that provides the second function shown in FIG. 6 to the IRP stored in the queue 81 will be discussed with reference to the flowchart of FIG. 81 process).

In FIG. 15, the process performed is similar to that described in the flowchart of FIG. 10 except for steps S156 to S159 for setting the pause flag.

In response to a call of an API function representing a request to perform an I/O-related process on the driver 2 by one of the processes 71 to 75 of the application programs 31 to 33, the Win32 subsystem 51 outputs a request to the NT I/O manager 52, and the NT I/O manager 52 provides the IRP corresponding to the function of the API to the PD filter 53 in response to the request output from the Win32 subsystem 51.

In the PD filter 53, in step S151, the filter core 53A receives the IRP requested by the AIP function of the NT I/O manager 52 that has been called. In step S152, the filter core 53A determines whether the IRP is an IRP_MJ_DEVICE_CONTROL IRP with IOCTL_PD_SET_PROCESSID (FIG. 8) specified as the IOCTL.

If it is determined in step S152 that the IRP received by the filter core 53A in step S151 is the IRP_MJ_DEVICE_CONTROL IRP specified as the IOCTL_PD_SET_PROCESSID of the IOCTL, the process goes to step S153. In step S153, the filter core 53A registers (stores) the process ID contained in the IRP, that is, the process ID of the process which has called the function corresponding to the IRPAPI, and waits for another IRP. Then the process returns to step S151.

That is, in step S153, the process ID of the process corresponding to the IRPAPI function received by the filter core 53A in step S151 that has been called is registered (registered process ID).

If it is determined in step S152 that the IRP requested by the process is not the IRP_MJ_DEVICE_CONTROL IRP with the IOCTL_PD_SET_PROCESSID designated as the IOCTL, the process goes to step S154 to determine whether the IRP is the IRP_MJ_DEVICE_CONTROL IRP with the IOCTL_PD_DELETE_PROCESSID (FIG. 8) designated as the IOCTL.

If it is determined in step S154 that the IRP is an IRP with IOCTL_PD_DELETE_PROCESSID designated as the IOCTL, the process goes to step S155. In step S155, the filter core 53A deletes the registered process ID and waits for another IRP. Then the process goes to step S11.

If it is determined in step S154 that the IRP is not the IRP with the IOCTL_PD_DELETE_PROCESSID designated as the IOCTL, the process goes to step S156 to determine whether the IRP is the IRP_MJ_DEVICE_CONTROL IRP with the IOCTL_PD_PAUSE_PROCESSID (FIG. 13) designated as the IOCTL.

If it is determined in step S156 that the IRP requested by the process is the IRP with IOCTL_PD_PAUSE_OTHERAPPIER specified as the IOCTL, the process goes to step S157. In step S157, the filter core 53A sets the suspend flag, which is a variable of 1, indicating an interrupt status, and waits for another IRP. Then the process goes to step S151. The filter core 53A (PD filter 53 ) then operates in the interrupted state.

If it is determined in step S156 that the IRP requested by the process is not the IRP with the IOCTL_PD_PAUSE_OTHERAPPIER designated as the IOCTL, the process goes to step S158 to determine whether the IRP requested by the process is the IRP_MJ_DEVICE_CONTROL IRP with the IOCTL_PD_RUN_OTHERAPPIER (FIG. 13) designated as the IOCTL.

If it is determined in step S158 that the IRP requested by the process is the IRP with IOCTL_PD_RUN_OTHERAPPIER specified as the IOCTL, the process goes to step S159. In step S159, the filter core 53A resets the suspend flag to 0 indicating the running state, and waits for another IRP. Then the process goes to step S151. Filter core 53A then runs in the run state.

If it is determined in step S158 that the IRP requested by the process is not the IRP with IOCTL_PD_RUN_OTHERAPPIER specified as the IOCTL, the process goes to step S160 to determine whether the IRP is an IRP indicating a request for access to the optical disc 3 .

If it is determined in step S160 that the IRP requested by the process is not an IRP representing an access request, that is, the IRP is an IRP_MJ_DEVICE_CONTROL IRP representing an IOCTL_PD_SET_PRIORITY ( FIG. 8 ) designated as an IOCTL that represents a request to change the IRP priority set by the PD filter 53 or An IRP_MJ_DEVICE_CONTROL IRP with IOCTL_PD_GET_PRIORITY (FIG. 8) designated as an IOCTL representing a get IRP priority request set by the PD filter 53, the process goes to step S161. In step S161, like step S57 among Fig. 10, filter core 53A executes the process based on IRP, and returns the process result as response to the process that has called the API function through NT I/O manager 52 and Win subsystem 51 , and wait for another IRP. Then the process returns to step S151.

If in step S160, determine that the IRP of process request is the IRP that represents access request, that is, IRP is the IRP_MJ_READ IRP that represents read file request or the IRP_MJ_WRITE IRP that represents write file request, then process goes to step S162. In step S162, the filter core 53A determines whether the process ID is included in the IRP requested by the process, that is, whether the process ID of the process that has called the API function corresponding to the IRP coincides with the registered process ID.

If it is determined in step S162 that the process ID contained in the RP requested by the process is inconsistent with the registered process ID, the process goes to step S163. In step S163, the filter core 53A sets the lowest IRP priority for the IRP requested by the process, and the process goes to step S165.

If it is determined in step S162 that the process ID contained in the IRP requested by the process coincides with the registered process ID, the process goes to step S164. In step S164, the filter core 53A sets the highest IRP priority for the IRP requested by the process, and the process goes to step S165.

In step S165, the filter core 53A outputs the IRP provided with the IRP priority set in step S163 or S164 to the queue 81 and stores it therein while waiting for another IRP. Then the process goes to step S151.

The process performed by the IRP stored on the queue 81 by the PD filter 53 performing the second function shown in FIG. 6 (the process for outputting an IRP from the queue 81) will be described below with reference to the flowchart of FIG.

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

If it is determined in step S171 that the suspend flag is set to 1, that is, the PD filter 53 is in the interrupted state, the process goes to step S172 to determine whether the highest IRP priority is set for the queue 81 .

If the highest IRP priority is set for the queue 81 in step S172, ie, an IRP requested by a process having a process ID identical to the registered process ID is stored in the queue 81, the process goes to step S173. In step S173, the filter core 53A processes the IRP having the highest IRP priority stored in the queue 81, and the process returns to step S171. That is, in step S173, the filter core 53A reads the IRP with the highest IRP priority from the queue 81 and outputs it to the PD_FS 54 through the NT I/O manager 52.

If it is determined in step S172 that the IRP with the highest IRP priority is not stored in the queue 81, that is, the IRP requested by the process with the process ID consistent with the registered process ID is not stored in the queue 81, the process skips the step S173 and return to step S171.

Therefore, if the PD filter 53 is in the interrupted state, an IRP requested by a process having a process ID different from the registered process ID is not output to the PD_FS 54.

If it is determined in step S171 that the suspend flag is reset to 0 again, that is, the PD filter 53 is in the running state, the process goes to step S174.

More specifically, like step S71 , in step S174 , the filter core 53A searches for the highest IRP priority among the IRPs stored in the queue 81 .

Like step S72, in step S175, the filter core 53A processes the IRP with the highest IRP priority found in step S174, while the process goes to step S171. More specifically, in step S175, the filter core 53A preferentially reads the IRP with the highest IRP priority from the queue 81 and outputs it to the PD_FS 54 through the NT I/O manager 52.

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

As discussed above, in the PD filter 53, the highest IRP priority is set for a process with the same process ID as the registered process ID, and the lowest is set for a process with a different process ID than the registered process ID. The IRP priority.

The PD filter 53 stores the IRPs provided by the IRP priorities in the queue 81 . If the PD filter 53 is in the running state, the IRPs stored in the queue 81 are processed according to the IRP priority. If the PD filter 53 is in the interrupt state, only the IRP provided by the highest IRP priority, that is, the IRP requested by the process having the same process ID as the registered process ID, is processed among the IRPs stored in the queue 81 .

Therefore, in the AV application 33 (FIG. 6), the PD_API 41 loaded by the process 75 requests the PD filter 53 to register the process ID of the process 75. Therefore, when the AV application 33 records or plays AV data, the PD_API 41 requests the PD filter 53 to be in an interrupted state. According to this arrangement, in the PD filter 53, the highest IRP priority is set for the IRP requested by the process 75 of the PD_API 41, and only the IRP provided with the highest IRP priority, i.e., only the one requested by the process 75 of the PD_API 41 IRP, can be processed and output to PD_FS 54.

Therefore, only IRPs requested by process 75 of PD_API 41 are processed. Thus, there is no need for the AV application 33 to wait until processing of the IRP from the application 31 or 32 is completed or an address request is generated on the drive 2 by the progress of the IRP from the application 31 or 32. Thereby, the interruption of the AV application 33 reading data from or writing data to the optical disc 3 can be prevented, and therefore, AV data can be recorded on or played back from the optical disc 3 in real time.

According to the first function, if the IRP requested by the process 75 of the PD_API 41 is not stored in the queue 81, the IRPs of the applications 31 and 32 may be output from the PD filter 53 to the PD_FS 54. Conversely, according to the second function, if the PD filter 53 is set to the interrupt state, even when the IRP requested by the process 75 of the PD_API41 is not stored in the queue 81, the IRPs of the applications 31 and 32 will not be received from the PD filter. 53 output to PD_FS 54.

In the flowcharts of FIGS. 15 and 16, when the PD filter 53 is in the interrupt state, only the IRP provided by the highest IRP priority is output to the PD_FS 54 as a specific IRP. Alternatively, only IRPs with process IDs consistent with registered process IDs can be output to PD_FS 54 as specific IRPs. That is, in the PD filter 53, only the IRPs identical to the registered process ID can be output to the PD_FS 54 without setting the IRP priority.

The PD third function for reliably and real-time reading and writing of AV data will be described below of the filter 53 .

More specifically, according to the third function, the PD filter 53 has a function switch for turning on or off the output of IRPs of applications other than the AV application 33, that is, from the applications 31 and 32, to the PD_FS 54 , thereby preventing the IRP of the application program 31 or 32 from outputting to the PD_FS54. By using this function, the PD filter 53 outputs only the IRP of the AV application 33 and not the IRP of the application 31 or 32 to the PD_FS 54, thereby ensuring that the AV application 33 can read and write AV data in real time.

FIG. 17 shows a structural example of the PD filter 53 that performs the third function described above.

In FIG. 17, the filter core 53A of the PD filter 53 has a switch 101 for turning on or off the output of the IRP of the application program 31 or 32 to the PD_FS 54.

When the OS 30 is running or when the optical disc 3 is set in the drive 2, the switch 101 is turned on or off according to the switch setting information stored in the register 58. It is difficult to change the state of the switch 101 after the volume corresponding to the drive 2 is installed.

The switch setting information is stored in the register 58 when the AV application 33 is installed. That is, when the AV application 33 is installed, the user is guided to select whether to turn the switch 101 on or off. The state of the switch 101 selected by the user is stored in the register 58 as switch setting information. The switch setting information stored in the register 58 can be changed on the selection screen for the AV application 33 after the AV application 33 is installed.

When the switch 101 is turned on, the PD filter 53 outputs the IRPs of all the applications (applications 31 to 33 in FIG. 17 ) to the PD_FS 54.

When the switch 101 was closed, the PD filter 53 only output the IRP from the PD_API 41 of the AV application program 33, and screened the file system on the volume of the optical disc 3 installed in the drive 2 correspondingly to other application programs 31 and 32, Thereby preventing the IRP of the application program 31 or 32 from outputting to the PD_FS 54.

In this case, in response to IRPs from other processes except PD_API 41, switch 101 returns a status value, which represents that although the volume has been placed, it can only be read and there are no files or directories in the volume.

浏览器上的文件。According to such a structure, when the switch 101 is turned off, the optical disc 3 set in the drive 2 is handled as a volume that does not provide files or directories so it is difficult to stop, reject, or format.

file on the browser.

Processing performed by the PD filter 53 shown in FIG. 17 using the third function will now be described with reference to the flowchart of FIG. 18 .

When the OS 30 starts or when the optical disc 3 is set in the drive 2, the filter core 53A acquires switch setting information from the register 58 in step S191.

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

The filter core 53A then waits for an IRP from one of the application programs 31 to 33, and receives the IRP in step S193.

In step S194, the filter core 53A determines whether the IRP received in step S193 is an IRP of the PD_API 41 of the AV application 33. If it is determined in S194 that the IRP received in step S193 is the IRP from the AV application 33, the process goes to step S195. In step S195, the filter core 53A outputs the IRP to the PD_FS 54 and waits for another IRP from one of the applications 31 to 33. Then the process goes to step S193.

If it is determined in S194 that the IRP received in step S913 is not the IRP from the AV application 33, that is, the IRP received in step S193 is from the application 31 or 32, then the process goes to step S196 to determine that the switch 101 Whether to close.

If it is determined in step S196 that the switch 101 is not off, that is, the switch 101 is on, the process goes to step S195. In step S195, the filter core 53A outputs the IRP received in step S193 to the PD_FS 54 and waits for another IRP from one of the applications 31 to 33. Then the process goes to step S193.

If it is determined in step S196 that the switch 101 is off, the process goes to step S197. In step S197, the switch 101 returns an anonymous reply of the file system, in which the file system is anonymous, that is, to the application 31 or 32, indicating that although the volume is mounted, there is no file or directory when reading. Status, which is the output source of the IRP received in step S193. The switch 101 then waits for another IRP from one of the applications 31-33. Then the process goes to step S193, at which time the process is similarly repeated.

As described above, in the PD filter 53, when the switch 101 is closed, only the IRP of the application 33 is output to the PD_FS 54. Thus, there is no need for the AV application 33 to wait until the processing of the IRP with respect to the application 31 or 32 is completed or an address request is generated on the drive 2 by the progress of the IRP of the application 31 or 32. Therefore, the interruption of the AV application 33 reading data from or writing data to the optical disc 3 can be prevented, and therefore, AV data can be recorded on or played back from the optical disc 3 in real time.

The determination as to whether the IRP is the IRP of the AV application 33 in step S194 may be determined in advance by registering the process ID of the process 75 in the PD filter 53 and determining whether the process ID of the IRP coincides with the registered process ID. .

In the embodiments described above, the first to third functions can all be performed in the PD filter 53 . But it can also be implemented in PD_FS 54.

The PD_FS 54 ( FIG. 4 ) performs the cache processing requested for using the caching function of the NT cache manager 59 for data requested by the IRP from the PD filter 53, as discussed in step S4 in FIG. 5 .

If the data requested by the IRP from PD Filter 53 is cached in NT Cache Manager 59, it is returned from PD_FS 54 to PD Filter 53. If the data requested by the IRP from PD Filter 53 is not cached in NT Cache Manager 59, it is output from PD_FS 54 to PD Memory 55.

Therefore, if the data cache requested by the IRP is cached in the NT cache manager 59, then the cache process will generate an additional overhead, that is, by executing the routine of the cache process, by the CPU 12 (FIG. 2) Contrast it with PC 1 without caching capabilities.

This overhead delays the output of the IRP from the PD_FS 54 to the PD memory 55, which further prevents recording or playback of AV data in real time. Therefore, it is necessary that no delay occurs when outputting the IRP from the AV application 33 .

Such delays can be prevented by not using the cache function.

If the cache function is not used at all, all IRPs from the PD filter 53 will be output from the PD_FS 54 to the PD memory 55. That is, all IRPs from applications 31 to 33 will be output from PD filter 53 to PD memory 55 through PD_FS 54.

More specifically, in this case, not only IRPs from AV application 33, but also from applications other than AV application 33, i.e., IRPs from applications 31 and 32 are also filtered from PD via PD_FS 54 The device 53 outputs to the PD memory 55. Thus, an addressing will result from reading the data requested by the application 31 or 32 .

The occurrence of this addressing prevents real-time reading of AV data from the IRP of the AV application 33 .

When using the cache function, if the data requested by the IRP from the application 31 or 32 is cached in the NT cache manager 59, the cached data is returned from the PD_FS 54 to the PD filter 53. In this case, the addressing generated on the drive 2 by reading the data requested by the IRP from the application program 31 or 32 from the optical disc 3 can be prevented.

Thus, in the AV application 33, a delay caused by performing cache processing can be prevented by not using the cache function. As a result, AV data can be better recorded or played back in real time.

In contrast, in the applications 31 and 32 other than the AV application 33, the addressing in the drive 2 is reduced due to the use of the cache function. As a result, it is also possible to record or play back AV data with improved real-time.

Therefore, in the PD filter 53, IRPs from the applications 31 and 32 are processed by using the cache function. On the other hand, for the IRP from the AV application 33, a cache ON/OFF function for setting whether to use the cache function is performed so that the IRP from the AV application 33 can be processed according to the setting value of the cache function.

FIG. 19 illustrates an example of the structure of the PD filter 53 that performs this cache ON/OFF function.

This cache ON/OFF function is provided only to the AV application 33, which loads the PD_API 41, and the applications 31 and 32 always use this cache function. That is, the cache ON/OFF function is associated with the application programs 31 and 32 . Therefore, only the AV application 33 providing the cache ON/OFF function is shown in FIG. 19 .

In FIG. 19 , the PD filter 53 has a command buffer 111 . The command buffer 111 temporarily stores the IRP in the PD_API 41 from the AV application 33, that is, the IRP output from the NT I/O manager 52 as a result of calling the API function by the PD_API 41.

In the PD filter 53 shown in FIG. 19 , the filter core 53A sets whether the cache function is used by the PD_API 41 of the AV application 33, and processes the AV application from the command buffer 111 according to the set result. IRP in program 33.

More specifically, if the cache function is used, the filter core 53A controls output to the PD_FS 54 of the IRP stored in the AV application 33 in the command buffer 111 in order to use the cache function in the PD_FS 54.

If the cache function is not used, the filter core 53A controls to output to the PD_FS 54 the IRP from the AV application 33 stored in the command buffer 111 so that the IRP is directly output to the PD memory without using the cache in the PD_FS 54 Function.

FIG. 20 shows an API function for letting the PD_API 41 control the PD filter 53 when the buffer ON/OFF function is used. This API function is output to the AV application 33 .

In FIG. 20, the API functions include four functions, namely, PdOpenFile(), PdcloseFile(), PdReadFile(), and PdWriteFile().

The four functions described above are all file stream API functions used to perform file processing. The API functions are similar to those four functions provided in the Win32 subsystem 51 .

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

The API function PdOpenFile() is an API function representing a request to open a file. It uses as parameters the file name (including the path name) of the file to be opened, the opening mode (for example, read-only mode) when the file is opened, and whether Use the cache information of the cache function as an argument.

By calling the API function PdOpenFile() by specifying the file name, open mode, and cache information as parameters, the file with the file name specified by the parameter can be opened in the open mode specified by the parameter. Furthermore, the API function PdOpenFile( ) allows the filter core 53A of the PD filter 53 to set whether to use the cache function according to the cache information as a parameter. In the API function PdOpenFile(), when the file is successfully opened, the file handle of the opened file is returned as the return value, and when the file fails to be opened, 0xffffffff is returned as the return value. 0x indicates that the subsequent values are in hexadecimal.

The API function PdCloseFile() is an API function representing a request to close a file, and it uses the file handle of the file to be closed as a parameter. The file specified by the file handle can be closed by calling the API function PdCloseFile() by specifying the handle of the file to be closed as a parameter. In the API function PdCloseFile(), when the file is successfully closed, 1 will be returned as the return value, and when the file close fails, 0 will be returned as the return value.

The API function PdReadFile() is an API function representing a request to read data from a file, and it uses a file handle of a file from which data is to be read, a buffer pointer pointing to a buffer temporarily storing data read from the file , and a number of bytes representing the size of the data to read from the file as an argument. By calling the API function PdReadFile() by specifying the file handle, buffer pointer, and number of bytes as parameters, the data of the specified number of bytes of the file specified by the file handle can be read and stored in the buffer in the storage area pointed to by the register pointer. In the API function PdReadFile(), when the data is read successfully, the number of bytes of the read data is returned as the return value, and when the data read fails, 0 is returned as the return value. The API function PdReadFile() responds to the API function PdReadFile() provided by the Win32 subsystem 51 .

The API function PdWriteFile() is an API function indicating a request to write data into a file, and it uses a file handle of the file to be written to, a buffer pointing to a buffer for temporarily storing data to be written to the file pointer, and as arguments a number of bytes representing the size of the data to be written to the file. By calling the API function PdWriteFile() by specifying the file handle, buffer pointer, and number of bytes as parameters, data of the specified number of bytes of the file specified by the file handle can be written and stored in the file specified by the file handle. In the memory area pointed to by the buffer pointer. In the API function PdWriteFile(), when the data is successfully read, the number of bytes of the read data is returned as the return value, and when the reading of the data fails, 0 is returned as the return value. The API function PdWriteFile( ) responds to the API function PdWriteFile( ) provided by the Win32 subsystem 51 .

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

Next, the Win32 subsystem 51 outputs a request to the NT I/O manager 52 in response to the API function DeviceIoControl(), and the NT I/O manager 52 converts the request into an IRP_MJ_DEVICE_CONTROL IRP and provides it to the PD filter 53.

As shown above, in IRP_MJ_DEVICE_CONTROL, IOCTL is specified by user-defined subcode.

Figure 21 illustrates the user-defined IOCTL specified by IRP_MJ_DEVICE_CONTROL when PdOpenFile(), PdCloseFile(), PdReadFile(), and PdWriteFile() are called.

In FIG. 21, four IOCTLs (subcodes), namely, IOCTL_PD_OPEN_FILE, IOCTL_PD_CLOSE_FILE, IOCTL_PD_READ_FILE, and IOCTL_PD_WRITE_FILE corresponding to PdOpenFile(), PdCloseFile(), PdReadFile(), and PdWriteFile() of the API functions shown in FIG. 20 Both can be used as user-defined IOCTL.

IOCTL_PD_OPEN_FILE is an IOCTL that is a subcode of the IRP_MJ_DEVICE_CONTROL IRP associated with the API function DeviceIoControl() that requests to open a file called in response to the API function PdOpenFile().

IOCTL_PD_CLOSE_FILE is an IOCTL that is a subcode of the IRP_MJ_DEVICE_CONTROL IRP associated with the API function DeviceIoControl() that requests to close a file called in response to the API function PdCloseFile().

IOCTL_PD_READ_FILE is an IOCTL that is a subcode of the IRP_MJ_DEVICE_CONTROL IRP associated with the API function DeviceIoControl() that requests to read a file called in response to the API function PdReadFile().

IOCTL_PD_WRITE_FILE is an IOCTL that is a subcode of the IRP_MJ_DEVICE_CONTROL IRP associated with the API function DeviceIoControl() that requests data to be written to a file called in response to the API function PdWriteFile().

As described above, the subcode IOCTL of the IRP_MJ_DEVICE_CONTROL IRP defined by the user is sent to the NT I/O manager 52 by using the API function DeviceIoControl () provided by the Win32 subsystem 51 and is controlled by the NT I/O manager 52 Specified as a subcode of the IRP_MJ_DEVICE_CONTROL IRP.

When the filter 53 performs the cache ON/OFF function, the entire process of the AV application 33, the PD_API 41 shown in FIG. 19, the PD filter 53, and the PD_FS 54 will be described below with reference to the flowchart of FIG. 22.

If reading of AV data from the optical disc 3 or writing of AV data to the optical disc 3 is performed without using the cache function, then in step S201, the AV application 33 invokes the request by using the cache information indicating that the cache function is not used as a parameter ( Cache is closed) and the API function PdOpenFile() to open the file.

In step S211, the PD_API 41 receives a call from the AV application 33 to the API function PdOpenFile(). Then, in step S212, in response to the calling of the API function PdOpenFile (), the PD_API 41 calls the API function DeviceIoControl () of requesting to open the file. Subsequently, the NT I/O manager 52 provides the IRP_MJ_DEVICE_CONTROL IRP with the IOCTL_PD_OPEN_FILE designated as the IOCTL requesting the PD filter 53 to open a file. In this case, IOCTL_PD_OPEN_FILE contains 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 resets the cache flag to 0 to indicate that the cache function is not used according to the IOCTL_PD_OPEN_FILE of the IRP. Therefore, a file requested to be opened by the cache information (cache off state) specified as a parameter in the AV application 33 can be processed without using the cache function (cache off state).

In the cache-closed state, in response to PD_API 41 for PdOpenFile(), PdcloseFile(), PdReadFile(), and PdWriteFile() respectively, the PD filter call 53 is directly output to PD_FS 54 in association with the API function DeviceIoControl() An IRP_MJ_DEVICE_CONTROLIRP with IOCTL_PD_OPEN_FILE specified as IOCTL, IOCTL_PD_CLOSE_FILE, IOCTL_PD_READ_FILE, and IOCTL_PD_WRITE_FILE. Therefore, the PD filter 53 controls the output of the IRP of the PD_API 41 so that the data requested by the IRP of the PD_API 41 can be read or written without using the cache function.

That is, in step S221, after setting the cache off state, the PD filter 53 directly outputs the IRP_MJ_DEVICE_CONTROL IRP received from the NT I/O manager 52 with IOCTL_PD_OPEN_FILE as the IOCTL to the PD_FS 54.

In step S231, the PD_FS 54 receives the IRP_MJ_DEVICE_CONTROL IRP with IOCTL_PD_OPEN_FILE from the PD filter 53 and outputs it to the PD memory 55. Next, open the file on disc 3.

Subsequently, if, in step S202, the AV application program 33 calls API functions PdReadFile () and PdWriteFile () that are opened or written to a file (file stream) as a request for accessing the optical disc 3, then in step S213 the PD_API 41 Receive calls to the API functions PdReadFile() and PdWriteFile().

In step S214, for responding to API function PdReadFile () and PdWriteFile () from AV application program 33 respectively, PD_API 41 call request reads or writes API function DeviceIoControl () of a file so that will have designated as request read file The IRP_MJ_DEVICE_CONTROL IRP of the IOCTL_PD_READ_FILE of the IOCTL or the IRP_MJ_DEVICE_CONTROL IRP of the IOCTL_PD_WRITE_FILE of the IOCTL designated as a request to write a file is supplied from the NT 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 I/O manager 52. In step S224, the PD filter 53 outputs the IRP_MJ_DEVICE_CONTROL IRP to the PD_FS 54.

As mentioned above, the PD filter 53 in the cache off state directly outputs the IRP_MJ_DEVICE_CONTROL IRP from the PD_API 41 to the PD_FS 54.

Therefore, in this case, in step S224, the PD filter 53 directly outputs the IRP_MJ_DEVICE_CONTROL IRP having the IOCTL_PD_READ_FILE designated as the IOCTL requesting to read the file or the IRP_MJ_DEVICE_CONTROL IRP having the IOCTL_PD_WRITE_FILE designated as the IOCTL requesting to write the file to the PD_FS 54.

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

In response to calling the API functions PdReadFile() and PdWriteFile() provided by the Win32 subsystem 51, the PD_FS 54 provides the cache function of the NT cache manager 59 to output from the NT I/O manager 52 to the PD filter 53 IRP_MJ_READ IRP or IRP_MJ_WRITEIRP. In contrast, PD_FS 54 does not provide caching for IRP_MJ_DEVICE_CONTROL IRPs.

Therefore, in step S232, the PD_FS 54 directly outputs the IRP_MJ_DEVICE_CONTROL IRP from the PD filter 53 to the PD memory 55. That is, the cache function is not used.

Subsequently, if, in step S203, the API function PdCloseFile () of the file that AV application program 33 calls requests to close in step S201, PD_API 41 receives the API function PdCloseFile () that is called by AV application program 33 in step S215 . Then, in step S216, in response to the calling of the API function PdCloseFile (), the PD_API 41 calls the API function DeviceIoControl () that requests the file to be closed so that the IRP_MJ_DEVICE_CONTROL IRP with the IOCTL_PD_CLOSE_FILE that is designated as the IOCTL that requests to close the file is sent from the NT I/O The manager 52 supplies to the PD filter 53 .

In step S225, the PD filter 53 receives the IRP from the NT I/O manager 52. In step S226, the PD filter 53 directly outputs the IRP to the PD_FS 54.

In step S233, the PD_FS 54 receives the IRP_MJ_DEVICE_CONTROL IRP with the IOCTL_PD_CLOSE_FILE designated as the IOCTL from the PD filter 53, and outputs it to the PD memory 55. Next, close the file on disc 3.

On the other hand, if in step S241, the reading of AV data from or writing of AV data to the optical disc 3 is performed using the cache function, the AV application 33 calls the request by using the cache function as a parameter The API function PdOpenFile() to open the file with the cache information (cache open).

In step S251, the PD_API 41 receives a call from the AV application 33 to the API function PdOpenFile(). Next, in step S252, in response to calling PD_API 41 to the API function PdOpenFile (), the API function DeviceIoControl () of requesting to open a file is called so that the IRP_MJ_DEVICE_CONTROL IRP of the IOCTL_PD_OPEN_FILE having the IOCTL designated as requesting the PD filter 53 to open a file is sent from NT I/O manager 52 supplies to PD filter 53. In this case, IOCTL_PD_OPEN_FILE contains cache information indicating that the cache function is used.

In step S261, the PD filter 53 receives the IRP from the NT I/O manager 52 and sets the cache flag to 1 to indicate that the cache function is used according to the IOCTL_PD_OPEN_FILE of the IRP. Therefore, a file requested to be opened by specifying cache information (cache on) as a parameter in the AV application 33 can be processed using the cache function (cache on state).

In the cache-on state, the PD filter 53 controls data requested by the IRP of the PD_API 41 to be read or written by using the cache function.

That is, in step S261, after setting the cache open state, the PD filter 53 outputs the IRP_MJ_DEVICE_CONTROL IRP received from the NT I/O manager 52 with the IOCTL_PD_OPEN_FILE specified as the IOCTL to the PD_FS 54.

In step S271, the PD_FS 54 receives the IRP_MJ_DEVICE_CONTROL IRP with the IOCTL_PD_OPEN_FILE specified as the IOCTL and outputs it to the PD memory 55. Next, open the file on disc 3.

Subsequently, if, in step S242, the AV application program 33 calls the API functions PdReadFile () and PdWriteFile () as a request to access the optical disc 3 (a request to open or write a file), then in step S253 the PD_API 41 receives a reference to the API Calls of the functions PdReadFile() and PdWriteFile().

In step S254, in response to the calling of API functions PdReadFile () and PdWriteFile () from the AV application program 33, the PD_API 41 calls the API function DeviceIoControl () that requests to read or write a file so as to specify as the request The IRP_MJ_DEVICE_CONTROL IRP of the IOCTL_PD_READ_FILE of the IOCTL that reads a file or the IRP_MJ_DEVICE_CONTROL IRP of the IOCTL_PD_WRITE_FILE with an IOCTL designated as a request to write a file is supplied from the NT 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 I/O manager 52. In step S264, the PD filter 53 outputs the IRP_MJ_DEVICE_CONTROL IRP to the PD_FS 54.

In this case, the PD filter 53 in the cache-on state converts the IRP_MJ_DEVICE_CONTROL IRP with IOCTL_PD_READ_FILE or the IRP_MJ_DEVICE_CONTROL IRP with IOCTL_PD_WRITE_FILE, and outputs the converted IRP to the PD_FS 54.

In step S264, in response to a call to the API function ReadFile() that requests to read a file provided by the Win32 subsystem 51, an IRP_MJ_DEVICE_CONTROL IRP with IOCTL_PD_READ_FILE is converted to be output from the NT I/O manager 52 to the PD filter 53 IRP_MJ__READ. The IRP_MJ__READ is then output to PD_FS 54.

IRP_MJ_DEVICE_CONTROLIRP with IOCTL_PD_WRITE_FILE is converted into IRP_MJ_WRITE output from the NT I/O manager 52 to the PD filter 53 in response to a call to the API function WriteFile() requesting to write to a file provided by the Win32 subsystem 51. This IRP_MJ_WRITE is then output to PD_FS 54.

In step S272, the PD_FS 54 receives the IRP_MJ_READ or IRP_MJ_WRITE from the PD filter 53.

As mentioned above, the PD_FS 54 provides the cache function to IOCTL_MJ_READ or IOCTL_MJ_WRITE through the NT cache manager 59.

In step S272, the PD_FS 54 reads or writes the IRP_MJ_READ or IRP_MJ_WRITE received by the slave PD filter 53 by using the cache function.

More specifically, if the data read from the IRP_MJ_READ IRP request from the PD filter 53 is cached in the NT cache manager 59, the PD_FS 54 returns the cached data to the PD filter 53 as a response. If the data requested by the IRP_MJ_READ IRP is not cached in the NT cache manager 59, the PD_FS 54 outputs the IRP_MJ_READ IRP from the PD filter 53 to the PD memory 55.

Subsequently, if in step S243, AV application program 33 has called the API function PdCloseFile () that request closes the file opened in step S241, then PD_API 41 receives in step S255 from AV application program 33 to API function PdCloseFile () transfer. Next, in step S256, in response to the calling of the API function PdCloseFile (), the PD_API 41 calls the API function DeviceIoControl () that requests to close the file so that the IRP_MJ_DEVICE_CONTROL IRP with the IOCTL_PD_CLOSE_FILE that the request file is closed is provided from the NT I/O manager 52 to PD filter 53.

The PD filter 53 receives the IRP from the NT I/O manager 52 in step S265. In step S266, the PD filter 53 outputs the IRP to the PD_FS 54.

In step S273, the PD_FS 54 receives the IRP_MJ_DEVICE_CONTROL IRP with IOCTL_PD_CLOSE_FILE from the PD filter 53, and outputs it to the PD filter 55. This will close the file on disc 3.

Depending on, for example, the performance of the PC 1 or the drive 2 (for example, the clock frequency of the CPU 12 or the worst seek time of the drive 2 ) or the user's operation, it can be determined whether the cache function is used, which is used as a call request to open a It is indicated in the cache information of the parameter of the API function PdOpenFile() of the file.

The process performed by the PD filter 53 by using the cache ON/OFF function shown in FIG. 19 will be described below with reference to the flowchart of FIG. 23 .

In response to one of the processes 71 to 75 of the application programs 31 to 33 requesting to perform the drive

The NT I/O manager 52 provides the IRP corresponding to the API function to the PD filter 53 by calling the API function of the request of the process related to the I/O by the actuator 2.

In this embodiment, the API functions (including PD_API 41) called by the application programs 31 to 33 include the API functions provided by the Win32 subsystem 51 and the API functions provided by the PD_API 41.

In response to the calling of the API function provided by the Win32 subsystem 51, the Win32 subsystem 51 outputs a request corresponding to the API function to the NT I/O manager 52, and the NT I/O manager 52 will respond to the request corresponding to the API function. The IRP of the API function is supplied to the PD filter 53 . In response to calls to API functions provided by PD_API 41, PD_API 41 calls the corresponding API function DeviceIoControl(). Then, in response to the API function DeviceIoControl(), the Win32 subsystem 51 outputs a request to the NT I/O manager 52, and the NT I/O manager 52 provides the corresponding IRP to the PD filter 53.

Therefore, no matter whether the API function called by one of the application programs 31 to 33 is the API function provided by the Win32 subsystem 51 or the API function provided by the PD_API 41, the IRP corresponding to the API function is finally transferred from the NT The I/O manager 52 supplies to the PD filter 53 .

In step S301, the PD filter 53 receives the IRP provided by the NT I/O manager 52 and stores it in the command buffer 111. Next, in step S302, the filter core 53A determines whether the IRP stored in the command buffer 111 in step S301 is an IRP_MJ_DEVICE_CONTROL IRP with IOCTL_PD_OPEN_FILE designated as IOCTL.

As mentioned above, IOCTL_PD_OPEN_FILE contains cache information.

If it is determined in step S302 that the IRP stored in the command buffer 111 is an IRP with the IOCTL_PD_OPEN_FILE designated as IOCTL, the process goes to step S303 to determine whether the cache information specified by the IRP in the IOCTL_PD_OPEN_FILE indicates that the IRP is used. cache function.

If it is determined in step S303 that the cache information indicates that the cache function is used, the process goes to step S304. In step S304, the filter core 53A sets the cache flag of the variable to 1 to indicate that the cache information is used (cache on state).

If it is determined in step S303 that there is no cache information indicating that the cache function is used, the process goes to step S305. In step S305, the filter core 53A sets the cache flag to 0 to indicate that the cache information is not used (cache off state).

In step S306, the filter core 53A outputs the IRP with IOCTL_PD_OPEN_FILE stored in the command buffer 111 to the PD_FS 54 and waits for another IRP. The process then returns to step S301.

In this case, PD_FS 54 receives the IRP from filter core 53A and outputs it to PD memory 55. Next, open the file.

If it is determined in step S302 that the IRP stored in the command buffer 111 is not the IRP with the IOCTL_PD_OPEN_FILE designated as IOCTL, then the process goes to step S307 to determine whether the IRP stored in the command buffer 111 is a request to close a file with IRP_MJ_DEVICE_CONTROL IRP specified as IOCTL_PD_CLOSE_FILE of the IOCTL.

If it is determined in step S307 that the IRP stored in the command buffer 111 is an IRP with IOCTL_PD_CLOSE_FILE, the process goes to S308. In step S308, the filter core 53A outputs an IRP with IOCTL_PD_CLOSE_FILE to the PD_FS 54 and waits for another IRP. Then the process returns to step S301.

In this case, PD_FS 54 receives the IRP with IOCTL_PD_CLOSE_FILE and outputs it to PD storage 55. Next, close the file.

If it is determined in step S307 that the IRP stored in the command buffer 111 is not the IRP with IOCTL_PD_CLOSE_FILE, then the process goes to S309 to determine whether the IRP_MJ_DEVICE_CONTROL IRP stored in the command buffer 111 is the IRP_MJ_DEVICE_CONTROL IRP with IOCTL_PD_READ_FILE or the IRP with IOCTL_PD_WRITE_FILE IRP_MJ_DEVICE_CONTROL IRP.

If it is determined in step S309 that the IRP stored in the command buffer 111 is not the IRP_MJ_DEVICE_CONTROL IRP with IOCTL_PD_READ_FILE or the IRP_MJ_DEVICE_CONTROL IRP with IOCTL_PD_WRITE_FILE, the process goes to step S310. In step S310, the filter core 53A outputs the IRP stored in the command buffer 111 to the PD_FS 54 and waits for another IRP. Then 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 with IOCTL_PD_READ_FILE or IOCTL_PD_WRITE_FILE, the process goes to step S311 to determine whether the cache flag is 1 or not.

If it is determined in step S311 that the cache flag is 1, that is, the filter core 53A of the PD filter 53 is in the cache-on state, the process goes to step S312. In step S312 , the filter core 53A converts the IRP stored in the command buffer 111 .

That is, in this case, the IRP stored in the command buffer 111 is an IRP_MJ_DEVICE_CONTROL IRP requesting to read a file with IOCTL_PD_READ_FILE designated as IOCTL or an IRP_MJ_DEVICE_CONTROL requesting to write a file with IOCTL_PD_WRITE_FILE designated as IOCTL IRPs.

If the IRP stored in the command buffer 111 is the IRP_MJ_DEVICE_CONTROL IRP with the IOCTL_PD_READ_FILE designated as the IOCTL for the request to read the file, then in step S312, in response to the call to the API function ReadFile () provided by the Win32 subsystem 51 , the filter core 53A converts the IRP_MJ_DEVICE_CONTROL IRP into the IRP_MJ_READ IRP output from the NT I/O manager 52 to the PD filter 53.

If the IRP stored in the command buffer 111 is an IRP_MJ_DEVICE_CONTROL IRP with an IOCTL_PD_WRITE_FILE designated as an IOCTL, then in step S312, in response to a call to the API function WriteFile() provided by the Win32 subsystem 51, the filter core 53A Convert the IRP_MJ_DEVICE_CONTROL IRP to the IRP_MJ_WRITE IRP output from the NT I/O manager 52 to the PD filter 53.

Next, in step S313, the filter core 53A outputs the IRP converted in step S312, ie, IRP_MJ_READ or IRP_MJ_WRITE, to the PD_FS 54, and waits for another IRP. Then the process returns to step S301.

In this case, the PD_FS 54 receives IRP_MJ_READ or IRP_MJ_WRITE from the filter core 53A, and uses the cache function to read or write the data requested by the IRP.

As mentioned above, the PD_FS 54 provides the cache function to IRP_MJ_READ or IRP_MJ_WRITE through the NT cache manager 59.

Therefore, if the IRP received from the filter core 53A is IRP_MJ_READ, the PD_FS 54 checks whether the data read by the IRP request is cached in the NT cache manager 59. If the data is cached in the NT cache manager 59, then the PD_FS 54 returns the cached data to the PD filter 53 as a response. If the data requested by the IRP_MJ_READ is not cached in the NT cache manager 59, the PD_FS 54 outputs the IRP_MJ_READ IRP to the PD memory 55.

The PD memory 55 includes a read/write buffer (not shown) for reading or writing data. The size of the read/write buffer is equal to the size of the page used, eg 4KB, and the maximum amount of data that can be read or written at one time is limited by the size of the read/write buffer.

Therefore, if the size of the data read requested by the IRP_MJ_READ from the filter core 53A exceeds the size of the read/write buffer, the PD_FS 54 divides the IRP_MJ_READ IRP into multiple request reads with the size of the read/write buffer IRP_MJ_READ IRP of the data, and output these IRPs to the PD memory 55. The same is provided to the IRP_MJ_WRITE from filter core 53A.

If it is determined in step S311 that the cache flag is not 1, that is, the cache flag is 0 and the filter core 53A of the PD filter 53 is in the cache off state, the process goes to step S314. In step S314, the filter kernel 53A directly outputs to the IRP stored in the command buffer 111 by the PD_FS 54, that is, an IRP_MJ_DEVICE_CONTROL IRP with IOCTL_PD_READ_FILE requesting to read a file or an IRP_MJ_DEVICE_CONTROL IRP with IOCTL_PD_WRITE_FILE requesting to write a file, and waits for Another IRP. Then the process goes to step S301.

In this case, the PD_FS 54 receives the IRP_MJ_DEVICE_CONTROL IRP with IOCTL_PD_READ_FILE or IOCTL_PD_WRITE_FILE, and immediately outputs the IRP to the PD memory 55 without using the cache function.

As described above, the maximum amount of data read or written at one time is limited by the size of the read/write cache of the PD memory 55 .

Therefore, if the amount of data to be read or written requested by the IRP_MJ_DEVICE_CONTROL IRP to be output to the PD_FS 54 in step S314 exceeds the size of the read/write cache, the filter core 53A divides the IRP_MJ_DEVICE_CONTROL IRP into multiple requests IRP_MJ_DEVICE_CONTROL IRPs of data to be read or written with read/write cache size and output these IRPs to PD_FS 54.

It can be selected whether or not the cache function is used by the cache ON/OFF function only for IRP_MJ_DEVICE_CONTROL IRPs with user-defined IOCTL codes shown in FIG. 21. The IRP with IOCTL is output from the NT I/O manager 52 to the PD filter 53 in response to a call to an API function provided only by the PD_API 41 shown in FIG. 20 .

Therefore, in this embodiment, the application that can use the cache ON/OFF function restricts the AV application 33 to load the PD_API 41.

If the cache function is not used in the AV application 33, the delay in processing the IRP of the AV application 33 due to the overhead of the cache processing on the IRP can be prevented, thereby allowing the AV application 33 to record in real time Or the operation of playing back AV data can be improved.

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

By using the cache function, the output frequency of the IRP from the application program 31 or 32 to the PD memory 55 or PD_FS 54 is reduced. It is thus possible to prevent addressing from taking place in the drive 2 due to an IRP request by the application 31 or 32 to read or write data. It is also possible to prevent addressing in the drive 2 caused by an IRP request of the AV application 33 to read or write data after an IRP request of the application 31 or 32 to read or write data. As a result, the operation of causing the AV application 33 to record or play back AV data in real time is improved.

Any of the first to third functions described above may be combined with the cache ON/OFF function.

FIG. 24 shows a structural example of the PD filter 53 when the first and second functions are combined with the cache ON/OFF function.

In FIG. 24, by using the first function, the PD filter 53 can set the IRP priority for the IRP representing a request to access the optical disc 3 from one of the application programs 31 to 33, and store the IRP provided by the IRP priority. In queue 81. Next, the PD filter 53 reads the IRP stored in the queue 81 according to the IRP priority set for the IRP, and outputs the IRP to the PD_FS 54.

Optionally, by using the second function, the PD filter 53 sets a suspend flag, which indicates whether the IRP process requesting access to the optical disc 3 is allowed or prohibited, and the PD filter 53 will receive the information from the applications 31 to 33 The IRPs are stored in queue 81. Next, 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.

In addition, the PD filter 53 sets whether the IRP of the AV application 33 uses the cache function, and when outputting the IRP to the PD_FS 54, the PD filter 53 processes the IRP according to the above setting.

FIG. 25 shows a configuration example of the PD filter 53 when the third function is combined with the cache ON/OFF function.

In FIG. 25, by using the third function, the PD filter 53 has a function to functionally turn on or off the output of an IRP to the PD_FS 54 of an application other than the AV application 33, that is, the application 31 or 32. switch 101, and the switch 101 is turned on or off according to the switch setting information stored in the register 58, thereby controlling the IRPs from the applications 31 and 32 output to the PD_FS 54.

In addition, the PD filter 53 sets whether the AV application 33 uses the cache function, and when outputting the IRP to the PD_FS 54, the PD filter 53 processes the IRP according to the above setting.

As described above, by combining the first to third functions with the cache ON/OFF function, addressing caused by the application 31 or 32 accessing the optical disk 3 can be prevented, thereby ensuring that the AV application 33 records or plays back in real time Operation of AV data.

In the above-described embodiments, the optical disc 3 can be used as a recording medium for recording or playing data. However, any other type of recording medium can be used, such as a hard disk or other optical disk-like recording medium capable of being addressed by recording or playing back data.

In this specification, the programs for the PC 1 to execute various types of processes formed by various steps do not need to be executed in the order described in the flow chart. They can be executed in parallel or individually (eg, parallel processing or object processing).

It can be understood that those skilled in the art can make various modifications, combinations, approximate combinations, or selections to the present invention according to needs or other factors within the scope of the appended claims or their equivalents.

Claims (8)

1. An information processing apparatus for processing an access request from an application program for accessing a recording medium, comprising: Setting means for setting the priority dedicated to the access request from the application program or permission information indicating whether to allow the access request from the application program to be processed; queue control means for storing access requests provided with priority or permission information in a queue; access request processing means for processing access requests stored in the queue according to priority or permission information; and The cache function setting device is used to set whether to use the cache function, Wherein, the access request processing device processes the access request according to whether the cache function is used 2. The information processing apparatus according to claim 1, wherein the setting means sets the priority of an access request from a prescribed application higher than that of an access request from another application. 3. The information processing apparatus according to claim 1, wherein the access request processing means continuously processes access requests from a prescribed application and processes access requests from other applications only when the permission information indicates that processing of access requests is permitted. 4. The information processing apparatus according to claim 1, wherein the access request processing means processes an access request from a prescribed application depending on whether or not to use a cache function. 5. The information processing apparatus according to claim 1, wherein the information processing apparatus is a filter driver for filtering access requests and transmitting the filtered access requests to the file system driver. 6. The information processing apparatus according to claim 1, wherein the data read from or written to the recording medium includes at least audio-video data. 7. The information processing apparatus according to claim 1, wherein, in the recording area of the recording medium, among continuous free areas having at least a predetermined size, a free area closest to a recording area where data is temporarily recorded just now is reserved while data is stored in that reserved free area. 8. An information processing method for processing an access request from an application program for accessing a recording medium, comprising the following steps: Set the priority dedicated to the access request from the application or permission information indicating whether to allow the access request from the application to be processed; store access requests provided with priority or permission information in a queue; and process access requests stored in queues based on priority or permission information; and Set whether to use the cache function, Among them, the access request is processed according to whether or not the cache function is used.

Images