JP4959766B2 - Device driver - Google Patents

Description

  The present invention relates to a device driver that controls an external peripheral device of a personal computer, and more particularly to a device driver that speeds up data transfer.

  In order for an operating system (hereinafter referred to as an OS) of a personal computer (hereinafter referred to as a PC) to normally recognize and control a peripheral device, software called a device driver is required.

  Many standard device drivers are incorporated in an OS installed in a recent PC. Therefore, when a standard peripheral device is connected, the OS automatically assigns a standard device driver, and recognizes and controls the connected peripheral device.

  However, the standard device driver is not optimized for each peripheral device, and a peripheral device that operates at a higher speed than the transfer speed controlled by the device driver (for example, an external HDD that reads / writes at a high speed). Even if it exists, standard device drivers limit speed. The application may also limit the speed.

  In particular, in the case of Windows (registered trademark), which is a general OS, when a USB mass storage device (external HDD or the like) is connected and data transfer is performed, an application or device driver equipped with Windows (registered trademark) as a standard is 64 kB. The USB mass storage driver adds information such as a command and status to each divided data. The time for processing information such as commands and statuses is long (several hundreds of microseconds), which causes a reduction in data transfer speed.

  FIG. 1 shows a functional block diagram of various drivers installed on the OS. In the figure, an application 51, a general-purpose disk driver 52, a USB mass storage driver 53, and a USB host controller driver 54 are function units mounted on the OS.

  The application 51 makes a read or write request to the USB mass storage device 55 (for example, an external HDD) via various drivers. In the figure, an example is shown in which the application 51 makes a write request and transfers data. The application 51 makes a write request to the general-purpose disk driver 52 and transfers data. The general-purpose disk driver 52 transfers this data to the USB mass storage driver 53 on the lower side. At this time, since the upper limit of the data transfer size of the USB mass storage driver 53 is 64 kB, the general-purpose disk driver 52 divides the data every 64 kB. The USB mass storage driver 53 gives a command and a status to the data divided every 64 kB, and sequentially transfers the data to the USB host controller driver 54. The USB host controller driver 54 sequentially transfers the command, data, and status to the USB mass storage device 55 using the USB bulk transfer method.

  FIG. 2 is a conceptual diagram showing the configuration of data (bulk-only protocol) transferred by the general-purpose disk driver 52 and the USB mass storage driver 53. As shown in the figure, the general-purpose disk driver 52 divides the data into 64 kB, and the USB mass storage driver 53 assigns commands and statuses to the respective data sections and sequentially transfers them to the USB host controller driver 54. Further, the USB host controller driver 54 sequentially transfers the command, the data divided into 64 kB, and the status to the USB mass storage device 55. As a result, the application 51 writes to the USB mass storage device 55.

  The time for the USB mass storage driver 53, the USB host controller driver 54, and the USB mass storage device 55 to process the command and status is about 500 μsec under the USB 2.0 standard environment. Then, every time 64 kB of data is transferred, a delay of about 500 μsec occurs together with the command and status processing time. If the total amount of data to be transferred is 64 kB or more, the data transfer speed decreases.

  Further, as shown in FIG. 1, even when the application 51 directly transfers data to the USB mass storage driver 53, the upper limit of the data transfer size of the USB mass storage driver 53 is 64 kB. The data is divided every time, and the USB mass storage driver 53 gives a command and a status to each data part and sequentially transfers them to the USB host controller driver 54. Note that even when there is no upper limit of the data transfer size of 64 kB on the driver side, and even when the application 51 transfers data larger than 64 kB, the application side may divide the data every 64 kB (for example, Windows (registered trademark) standard Explorer).

  Therefore, in any case, when the total amount of data to be transferred exceeds a predetermined amount, there has been a problem that the transfer speed is lowered.

  On the other hand, conventionally, as a technique for improving the transfer speed between a PC and a device, there has been a method in which a buffer is provided in a device controller, data is cached in the buffer, and transferred collectively (for example, see Patent Document 1). . The device of Patent Literature 1 directly transfers data exceeding the buffer capacity without going through the buffer because the writing process occurs whenever the total capacity of the transferred data exceeds the capacity of the buffer. .

  In addition, a plurality of buffers are provided to improve the transfer speed by caching data from the upper side in another buffer while performing processing to transfer data in one buffer (see, for example, Patent Document 2), A command that caches each command, data, and status and processes them together has been proposed (see, for example, Patent Document 3).

  In addition, when it is necessary to divide and process data as described above on the PC side and device side, the device controller on the PC side transfers a certain amount of data and transfers it again by the control unit on the device side. Have been proposed (see, for example, Patent Document 4).

JP-A-4-130523 JP 2002-344537 A JP 2006-215891 A JP 2001-154811 A

  However, the apparatus described in Patent Document 1 cannot increase the speed when an application or driver divides data. The devices described in Patent Document 2 and Patent Document 3 can improve the processing speed of the transfer unit, but cannot increase the speed when an application or driver divides data.

  Further, the computer system described in Patent Document 4 needs to divide and process data again by the control unit on the device side. Further, at the time of reading, a configuration is required in which the divided requests are integrated and transferred in the device-side control unit.

  SUMMARY OF THE INVENTION Accordingly, an object of the present invention is to provide a device driver that improves the transfer speed without requiring a special configuration on the device side when the total amount of data to be transferred is a predetermined amount.

  The device driver of the present invention is mounted on the OS of a personal computer to which a peripheral device is connected, and is placed on the lower side of software that sequentially transmits a write request for the peripheral device by dividing it into a plurality of commands with an upper limit data transfer size. A device driver, wherein the personal computer caches data corresponding to the write request, and when the driver receives a write request of the upper limit data transfer size, Then, it is predicted that a write request will be made, and a command end for each command is returned in a pseudo manner to the upper side, and data transferred from the upper side is sequentially cached in the cache memory, and each of the software divided A data larger than the upper limit of the data transfer size per command Wherein the control unit issues a command data transfer size performs processing of transferring the data of the cache memory in the peripheral device, to the be made to function.

  The device driver of the present invention is installed in the OS of a personal computer to which a peripheral device is connected, and is a lower level of software that sequentially transmits a read request to the peripheral device by dividing it into a plurality of commands with an upper limit data transfer size. A device driver arranged on the side, wherein the personal computer caches data corresponding to the read request, and the driver receives a read request for the upper limit data transfer size. It is predicted that a read request will be made continuously thereafter, and a command having a data transfer size larger than the upper limit of the data transfer size for each command divided by the software is issued to read data from the peripheral device, and the cache Perform processing to cache in memory, then higher Wherein for a control unit to be transferred from the cache memory the data to the upper side, characterized in that to function in the case where data corresponding to the command et sequentially transmitted read request is cached in the cache memory.

  As described above, the device driver of the present invention integrates the read / write requests received from the higher-order application and the device driver and transfers them to the device. As a result, the data received from the application or device driver is cached and transferred to the target device as a certain amount of data. Conversely, a certain amount of capacity is collectively received from the target device, and sequentially transferred to the application or device driver as cached data. Even when an application or device driver limits the transfer data capacity and divides and transfers the data, it issues a single command (or a reduced number) and status and transfers it. By doing so, speeding up is realized. When a read request is received, if data corresponding to the request is stored in the cache memory, it can be transferred. If the data once transferred is cached, it can be transferred at high speed the next time a read request for the same data is received. In general, since random access of a storage device is accompanied by a seek operation of the head, this causes a decrease in transfer speed. However, by transferring data from the cache memory as described above, issuing a read request to the target device The frequency can be reduced, and the frequency of occurrence of random access of the target device can be reduced, and further speedup can be realized.

  According to the present invention, since the data exceeding the data amount limited by the application or the device driver can be transferred, the transfer speed can be improved.

2 is a block diagram showing a PC and an external HDD connected by a USB interface. FIG. It is the conceptual diagram which showed the structure of the bulk only protocol. It is a block diagram of PC and external HDD in this embodiment. 3 is a functional block diagram of various drivers installed on the OS 11. FIG. 3 is a functional block diagram illustrating a detailed configuration of an upper driver 151 and a lower driver 152. FIG. 3 is a functional block diagram of various drivers installed on the OS 11. FIG. 3 is a flowchart showing the operation of the upper driver 151. 5 is a flowchart showing the operation of a lower driver 152. It is a flowchart which shows the operation | movement at the time of a command end interruption. It is a flowchart which shows the operation | movement at the time of a timer interruption, initialization, and a driver termination. It is a block diagram which shows the other example which implement | achieves the device controller of this invention. It is a functional block diagram which shows a structure in case the high-order side driver 151 and the low-order side driver 152 perform another operation | movement.

  Windows (registered trademark) is a commonly used OS installed on a PC. In the present embodiment, a case where an external HDD with a USB interface is connected to a PC equipped with Windows (registered trademark) XP will be described with reference to the drawings. In the present invention, the type of OS, the type of connected device, and the interface are not limited.

  FIG. 3 is a block diagram of the PC and the external HDD in this embodiment. The PC 1 and the external HDD 2 are connected by a USB interface (I / F). The PC 1 includes an application 101 that performs various processes and a driver 102 that includes various drivers for operating peripheral devices on an OS 11 that manages the whole. The application 101 reads (reads) data stored in the external HDD 2 via the driver 102, the USB controller 12, and the USB I / F 13, and writes data to the external HDD 2 (write).

  In the external HDD 2, the controller 22 receives a read or write request via the USB I / F 21, and reads data stored in the HDD 23 or writes data to the HDD 23 in response thereto.

  FIG. 4 is a functional block diagram of various drivers installed on the OS 11. In the figure, an application 101, a general-purpose disk driver 502, a USB mass storage driver 503, a USB host controller driver 504, an upper driver 151, and a lower driver 152 are functional units mounted on the OS 11. Actually, these functional units are realized as software installed in the OS 11.

  The application 101 makes a read or write request to the external HDD 2 via various drivers included in the driver 102. FIG. 2 shows an example in which the application 101 makes a write request and transfers data.

  The application 101 makes a write request to the higher-level driver 151 and transfers data to be written to the HDD 23 of the external HDD 2. The upper driver 151 transfers this write request and data to the lower-level general-purpose disk driver 502, and uses the information indicating the write request from the application 101 and the amount of data as access information as the lower driver 152. Send to. The access information transferred from the upper driver 151 to the lower driver 152 will be described in detail later.

  The general-purpose disk driver 502 transfers the data received from the upper driver 151 to the USB mass storage driver 503. At this time, since the upper limit of the data transfer size of the USB mass storage driver 503 is 64 kB, the general-purpose disk driver 502 transfers the data to the USB mass storage driver 503 by dividing it into 64 kB.

  The USB mass storage driver 503 assigns a command and a status to the data divided into 64 kB in order to perform data transfer by the bulk-only protocol (see FIG. 2), and sequentially transfers the data to the lower driver 152.

  The lower driver 152 caches the data transferred from the USB mass storage driver 503 and transfers the data to the USB host controller driver 504 at a predetermined timing. The USB host controller driver 504 transfers this data to the external HDD 2. Since the lower-level driver 152 caches the data transferred from the USB mass storage driver 503 and transfers it to the USB host controller driver 504 as a certain amount of data (64 kB or more), the command and status are issued 1 (Or less than every 64 kB). Therefore, the delay due to the command and status processing time can be minimized. The data transferred from the general-purpose disk driver 502 to the lower-level driver 152 is given a command and status every 64 kB. Since this transfer is memory (RAM) transfer on the OS, the external HDD 2 It is very fast compared to the data transfer rate to (depending on the RAM transfer rate).

In this embodiment, the application 101 may directly transfer data to the USB mass storage driver 503. As described above, since the upper limit of the data transfer size of the USB mass storage driver 503 is 64 kB, the application 101 has 64 kB. The data is divided for each transfer, and the USB mass storage driver 503 transfers the data with the command and status. Even in this case, since the lower-level driver 152 caches the data and then transfers the data to the lower-level side, the delay due to the command and status processing time can be minimized.
Next, detailed operations of the upper driver 151 and the lower driver 152 will be described. FIG. 5 is a functional block diagram showing a detailed configuration of the upper driver 151 and the lower driver 152. In addition, about the structure which is common in FIG. 4, the same code | symbol is attached | subjected and the description is abbreviate | omitted. The upper driver 151 includes a read / write request receiving unit 155. The lower driver 152 includes a controller 156, a database 157, cache memories 158A to 158C, a timer 159, and a command queue 160.

  The read / write request receiving unit 155 receives a read or write request from the application 101. The read / write request receiving unit 155 transfers this request to the lower-level general-purpose disk driver 502 and transmits the content of the request to the lower-level driver 152 as access information. The read or write request is transferred to the lower-level driver 152 via the general-purpose disk driver 502 and the USB mass storage driver 503.

  The access information includes LBA (Logical Block Addressing: HDD sector designation number), the number of transfer blocks, the transfer direction, and the like. The number of transfer blocks indicates the capacity of transfer data. The transfer direction is information indicating whether the transfer is from the lower side to the upper side (read) or from the upper side to the lower side (write).

  This access information is stored as a prediction database in the database 157 of the lower-level driver 152. When the controller 156 of the lower driver 152 receives a read or write request from the USB mass storage driver 503, the controller 156 refers to the database 157. By referring to the prediction database, the transfer data capacity can be predicted.

  Further, the controller 156 stores the read or write request received from the USB mass storage driver 503 in the database 157 as a history database. The history database is used when the controller 156 creates and corrects the prediction database. That is, when a read or write request is received from the USB mass storage driver 503, the past history database is referenced, and the LBA, the number of transfer blocks, and the transfer direction are the same or partially match (similar) are assumed as the expected database. copy. Also, if there is a matching history, the history related to this (for example, one that can be determined to have been continuously requested based on the LBA and the number of transfer blocks) is collected and stored as one command in the prediction database. You can also. In the figure, the history database is stored in the database 157 and temporarily stored in the RAM. However, the history database may be stored in the OS 11 of the PC 1 or the HDD 23 of the external HDD 2. . Thereby, the past history can be referred to even when the external HDD 2 is reconnected or the PC 1 is restarted.

  If the request transferred from the USB mass storage driver 503 is a write request, the controller 156 can predict the transfer data capacity by referring to the number of transfer blocks in the prediction database. At this time, when the upper driver 151 transmits access information to the lower driver 152 and is stored in the prediction database, the transfer data capacity (all data to be written) can be predicted. When the controller 156 predicts that data transfer of 64 kB or more will be performed, the controller 156 stores the data transferred from the upper side in any of the cache memories 158A to 158C.

  The cache memories 158A to 158C are areas virtually formed on the RAM, and the number and capacity thereof are set by the controller 156. The number and capacity of the cache memories can be set as appropriate, but in the example shown in the figure, it is assumed that three cache memories are prepared and each has a capacity of 1 MB. It is also possible to change the number and capacity of cache memories during operation. The number and capacity of the cache memories may be set manually by the user, or may be changed as appropriate according to the operating state as will be described later.

  As described above, the controller 156 sequentially stores the data transferred from the higher-order side in any one of the cache memories 158A to 158C. The cache memory storing the write data becomes the write cache memory. However, since a command and status are assigned every 64 kB from the USB mass storage driver 503 and data is transferred, the controller 156 pseudo-ends the command to the USB mass storage driver 503 every time 64 kB data is received. Reply to

  The controller 156 makes a write request to the lower USB host controller driver 504 at a predetermined timing, and transfers the data in the write cache memory. This predetermined timing is the timing when the capacity of the write cache memory is full or the timing determined by the interrupt processing of the timer 159. The controller 156 activates the timer 159 when receiving a write request from the USB mass storage driver 503. Even when the capacity of the write cache memory becomes full, a write request is sent to the USB host controller driver 504 to transfer the data in the write cache memory.

  When other processing is performed on the lower side below the USB host controller driver 504, the controller 156 once registers a write request in the command queue 160, and then writes when the lower side processing is free. Make a request. If there is no timer, the contents of the write cache memory are held as they are and cannot be written to the HDD 23. Therefore, when an abnormality occurs in this state (when the USB cable is disconnected or the PC 1 is hung up), the HDD 23 is originally used. Data that should have been written to is discarded, and damage such as file corruption is assumed. For this reason, for example, when a state in which no command is issued has elapsed for a certain period of time using a timer, the contents of the write cache memory are written to prevent file destruction at the time of abnormality.

  Data is written from the application 101 as described above. Next, FIG. 6 shows an example in which the application 101 makes a read request and transfers data.

  FIG. 6 is a functional block diagram of various drivers installed on the OS 11. In addition, about the structure which is common in FIG. 4, the same code | symbol is attached | subjected and the description is abbreviate | omitted.

  First, the application 101 makes a read request to the higher-level driver 151. The higher-level driver 151 transfers this request to the lower-level general-purpose disk driver 502 and transmits a read request (access information) from the application 101 to the lower-level driver 152.

  The general-purpose disk driver 502 transfers the read request received from the upper driver 151 to the USB mass storage driver 503. At this time, since the upper limit of the data transfer size of the USB mass storage driver 503 is 64 kB, the general-purpose disk driver 502 divides the read request every 64 kB. The USB mass storage driver 503 transfers the read request divided every 64 kB to the lower driver 152.

  When the low-order driver 152 receives a read request divided every 64 kB from the USB mass storage driver 503, the low-order driver 152 predicts that the read request will be continuously issued thereafter, and transfers a certain amount of data. A prediction read request is sent to the USB host controller driver 504. The USB host controller driver 504 reads a certain amount of data from the HDD 23 of the HDD 2 based on the predicted read request. This read data is cached in the lower driver 152. The lower driver 152 sequentially transfers the cached data to the upper side in accordance with the read request received from the USB mass storage driver 503. The certain amount of capacity may be set as appropriate. However, if the transfer capacity is too large, the transfer speed becomes slow. That is, since the transfer of the data cached on the upper side cannot be started until the end of the transfer is waited and the status of the normal end of the transfer is confirmed, the transfer speed becomes slow. In addition, it is necessary to increase the capacity of the read cache memory.

  Therefore, when the controller 156 first receives a read request of 64 kB (or less, it may be 32 kB, etc.), the controller 156 reads data having a capacity of a predetermined multiple (for example, 128 kB that is four times 32 kB). Cache. When all the cached data is transferred to the upper side as a result, data having a capacity of a predetermined multiple (for example, 512 kB which is four times 128 kB) is read. In this way, by sequentially increasing the capacity of the data to be cached, it is possible to set a suitable capacity of the read cache memory while suppressing the transfer time.

  In this way, the lower-level driver 152 reads a certain amount of capacity from the external HDD 2 at a time and caches it, thereby issuing commands and statuses to the external HDD 2 at a time (or by giving every 64 kB). Less). Therefore, the delay due to the command and status processing time can be minimized. Note that the data transferred from the lower-level driver 152 to the general-purpose disk driver 502 is divided into 64 kB, but since this transfer is a memory (RAM) transfer on the OS, the data transfer rate from the external HDD 2 is increased. It is very fast compared (depends on the RAM transfer rate).

  With reference to FIG. 5, detailed operations of the upper driver 151 and the lower driver 152 when the read request is generated will be described. The read / write request receiving unit 155 receives a read request from the application 101. The read / write request receiving unit 155 transfers this request to the lower-level general-purpose disk driver 502 and transmits the content of the request to the lower-level driver 152 as access information. The read request is transferred to the lower driver 152 via the general-purpose disk driver 502 and the USB mass storage driver 503. Note that read requests transferred from the general-purpose disk driver 502 and the USB mass storage driver 503 are divided into read requests every 64 kB.

  The access information transmitted by the upper driver 151 is stored in the database 157 of the lower driver 152 as a prediction database. When the controller 156 of the lower driver 152 receives a read request from the USB mass storage driver 503, the controller 156 refers to the database 157. By referring to the prediction database, the transfer data capacity (all data to be read) can be predicted.

  Further, the read request received from the USB mass storage driver 503 is stored in the database 157 as a history database. The history database is used when the controller 156 creates and corrects the prediction database. That is, when a read request is received from the USB mass storage driver 503, a past history database is referred to, and an LBA, the number of transfer blocks, and a transfer direction that are the same or similar are transferred as a prediction database. If there is a matching history, the history related to this (for example, it can be determined that there is a continuous request based on the LBA and the number of transfer blocks) can be collected and stored as one command in the prediction database. .

  When the controller 156 receives a read request from the USB mass storage driver 503, the controller 156 can predict the transfer data capacity (all data to be read) by referring to the number of transfer blocks in the prediction database. When the controller 156 predicts that data transfer of 64 kB or more will be performed, it makes a read request to the USB host controller driver 504 to transfer data of 64 kB or more described in the prediction database, and the transferred data is transferred to the cache memory. Store in one of 158A to 158C.

  The cache memory storing this data becomes the read cache memory. The controller 156 sequentially transfers the data in the read cache memory in response to the read request transferred from the USB mass storage driver 503. When the upper driver 151 transmits access information for all data to be read, all data can be accurately cached in the read cache memory, but the application 101 directly reads the USB mass storage driver 503. When making a request or when the higher-level driver 151 does not transmit access information for all data to be read, it is necessary to create a prediction database when the controller 156 receives a read request from the higher-level side. In this case, the history database may be referred to as described above. For example, when a read request of 64 kB (or less) is received for the first time, it is predicted that a predetermined amount of data will be read from the start LBA continuous with the read request. When a read request for the predicted start LBA is received from the higher-level driver, the predicted capacity is read, and when all predicted data is read from the higher-level driver, the start that continues to the predicted read It is predicted that a predetermined amount of data is read from the LBA.

  Data is read from the application 101 as described above.

  Next, operations of the upper driver 151 and the lower driver 152 will be described with reference to flowcharts. FIG. 7A is a flowchart showing the operation of the upper driver 151. When the upper driver 151 receives a read / write request from the application, the upper driver 151 transmits the content of the request to the lower driver 152 as access information (s1). The upper driver 151 transfers a read / write request to the lower side (general-purpose disk driver 502) (s2). The access information is stored as a prediction database in the database 157 of the lower driver 152.

  Note that the upper driver 151 can also perform the operations shown in FIGS. 7B and 12. FIG. 7B is a diagram showing another operation of the upper driver 151, and FIG. 12 is a functional block diagram showing a detailed configuration of the upper driver 151 and the lower driver 152 when this operation is performed. is there. In addition, about the structure which is common in FIG. 5, the same code | symbol is attached | subjected and the description is abbreviate | omitted.

  In FIG. 7B, when the upper driver 151 receives a read / write request from an application, the upper driver 151 determines whether or not the transferred data capacity is equal to or larger than a predetermined amount (for example, 64 kB or more) (s5). If the amount is not greater than the predetermined amount, the contents of the request are transferred as access information to the lower driver 152 (s6), and the read / write request is transferred to the general-purpose disk driver 502 (s7). If it is equal to or larger than the predetermined amount, as shown in FIG. 12, the read / write request is directly transferred to the controller 156 of the lower driver 152 (s8). In this case, no read / write request is transferred to the general-purpose disk driver 502. By transferring the read / write request directly to the controller 156, the data can be transferred to 64 kB without being divided. Further, since the general-purpose disk driver 502 and the USB mass storage driver 503 are not used, the processing time can be shortened and higher speed can be expected. If the data capacity to be transferred is not a predetermined amount or more, the USB mass storage driver 503 can process the data at a time, so that it is transferred to the lower level (general-purpose disk driver 502).

  Note that it may be determined whether or not the request is a read request instead of the process of s5. If it is a read request, it is directly transferred to the controller 156 of the lower driver 152. The controller 156 performs prediction processing when a read / write request is received from the upper side (USB mass storage driver). In particular, when reading, a certain amount of data capacity is read from the device side based on the prediction result and cached. Since a reply is sent from the top to the top, there is a possibility that a delay will occur. Therefore, at the time of a read request, this request is directly transferred from the higher-level driver 151 to the controller 156, and the transfer time (time until the start of transfer) can be shortened without performing prediction processing or cache processing.

  It should be noted that either one of the determination as to whether the request is a read request and the determination at s5 may be performed, or both may be performed. Other determination methods may be used. For example, when it is important to read data from the device side in advance and cache it (when the application repeatedly accesses the same data contents), the request is transferred directly to the controller 156 even at the time of a read request. Without transferring to the lower side. When the upper driver 151 transfers a read / write request directly to the controller 156 of the lower driver 152, data is not accumulated in the cache memory. Therefore, if the application accesses the same file, it may be transferred to the lower side so that the data is accumulated in the cache memory. However, by transferring the data and copying the data to the cache memory by the lower driver 152, the data can be accumulated even when a direct read / write request is received. In this case, since the copy is on the RAM, the copy speed is high, and the processing speed is not significantly reduced.

  FIG. 8 is a flowchart showing the operation of the lower driver 152. This operation is started when a read request, write request, or other request is received from the higher-level driver (USB mass storage driver 503 or application 101).

  First, the lower driver 152 performs access prediction (s11). Access prediction is performed by referring to access information and a history database transmitted from the higher-level driver 151. Further, the access prediction may be performed accurately as follows.

(1) Prediction Based on File System This prediction method is a method for performing access prediction by analyzing the file system of the external HDD 2. When the HDD file system is, for example, the FAT file system format, the recording position (sector) and size of each file can be determined by referring to the file management area. Therefore, when there is a read request from an upper application or driver, it is predicted that there is access to the file data corresponding to the recording position indicated by the request. In addition, by predicting that reading exceeding the file size will not be performed, unnecessary processing time is reduced without excessive reading.

  Since this file management area is an area that is frequently accessed, it may be read and held in the read cache memory. Even when the HDD 2 is not accessed each time, the access prediction processing time can be reduced by accessing the file management area held in the read cache memory.

(2) Prediction based on device type and content type This prediction method is a method of performing access prediction based on the type of target device to be connected (HDD in the above embodiment) and the file configuration (content type) of data to be transferred. It is. For example, when the device to be connected is a DVD-ROM and a DVD-Video medium is inserted in this device, reading is sequentially performed and no write request is made. Therefore, a prediction database is created so that data is cached to the full capacity of the read cache memory. When all the data cached in the read cache memory is read, the read cache memory can be used efficiently if the cache is immediately discarded and new data is cached.

  Further, when changing the number and capacity of cache memories, they can be changed based on the device type. For example, when a DVD-Video medium is inserted as described above, no write request is made, so the number of read cache memories is increased and the capacity thereof is set to be large. Conversely, when an unwritten DVD-R medium is inserted, a write request is mainly made, so the number of write cache memories is increased and the capacity thereof is set large.

(3) Prediction based on transfer rate analysis This prediction method is an application example of prediction based on the above device type and content type, and determines a data transfer rate trend according to the device type, and access prediction based on this It is a technique to do. For example, when a multi-layer DVD medium is connected, a random access exceeding the boundary line of each layer has a very low transfer rate. Therefore, the prediction database is created by caching so that the frequency of access across the boundary lines of each layer is low.

  Further, when changing the number and capacity of the cache memories, they can be changed based on the tendency of the device type and data transfer speed. For example, when the data transfer speed with the target device is slow (for example, about 4 MB / s as in USB MO (magneto-optical disk)), even if a large amount of data is cached by increasing the capacity of the cache memory, In the first place, since the data transfer speed is slow, it is not possible to improve the transfer speed. For this reason, when the data transfer rate with the target device is slow, the cache memory capacity is set to be small, and the RAM consumption is suppressed.

(4) Method of gradually increasing data to be transferred at a time at the time of a read request This prediction method is performed once from a target device based on the read request predicted by the methods (1) to (3) above at the time of a read request. This is a method of correcting (dividing) the prediction database so that data is not transferred to the network. For example, the prediction database is modified so that data having a predetermined capacity (for example, four times) of the read request is first cached. When all the cached data is transferred to the upper side as a result, the prediction database is corrected so as to cache data of a predetermined multiple capacity. Sequentially increasing the capacity of the data to be cached can reduce the transfer time. Further, it is possible to reduce the amount of data that is wasted when the actual request is different from the prediction database and there is no read thereafter. In addition, the consumption of RAM can be suppressed by changing the capacity of the cache memory each time. Note that the prediction database correction processing may be performed when reading is actually performed (during the processing of s29 described later).

  Access prediction is performed as described above. Note that the number and capacity of the cache memory can be manually set by the user. In addition, the number of reserved cache memories for write and read can be set by the user. If the user wants to give priority to reading, the number of read cache memories is increased. If the user wants to give priority to writing, the number of write cache memories is increased.

  Next, in FIG. 8, the lower driver 152 determines the content of the request transmitted from the upper side (s12). If the request is not a read / write request, it is determined whether the target device is performing another read / write process (s13). If the process is not available, the request is transferred to the lower side (s14). . If other processing is being performed, this request is registered in the command queue (s15). If it is registered in the command queue, it can be executed when the process becomes available later. When a command for instructing writing of data in the write cache memory such as the FLUSH CACHE command is received, the data cached in the write cache memory at this time is transferred to the lower side.

  In s12, when the lower driver 152 determines that the request is a read / write request, the lower driver 152 refers to the cache memory (s16). Here, if the request from the upper side is a read request and the corresponding data is cached in the read cache memory or the write cache memory, it is transferred to the upper side, and the command end is returned (s17).

  In s12, if the lower driver 152 determines that the request from the upper side is a continuous write request, the lower driver 152 continuously writes data in the write cache memory and returns a command end (s18). Thereafter, it is determined whether the capacity of the write cache memory is full (s19). If the capacity is not full, a timer is started (s20), and the operation ends.

  In s19, if the capacity of the write cache memory is full, it is determined whether or not the target device is performing another read or write process (s21). If the process is free, the write request is sent to the lower side. And cached data is transferred (s22). If other processing is being performed, this write request is registered in the command queue (s23). If it is registered in the command queue, it can be executed when the process becomes available later.

  If the lower driver 152 determines in step s16 that there is no cache data corresponding to the request from the upper side, the lower side driver 152 refers to the prediction database and compares the request from the higher side with the content of the prediction database (s24). If the request from the upper side does not match the contents of the prediction database (the LBA and the number of transfer blocks do not match), the request is transferred to the lower side as it is (s25). At this time, if the lower side is performing other processing, it may be registered in the command queue and executed later.

  If the request from the upper side is a write request and matches the contents of the expected database (the LBA and the number of transfer blocks match), the write cache memory is secured (s26). Here, if there is an empty cache memory, the cache memory is secured as a write cache memory, and when the cache memory is all used for writing or reading, the contents of the cache memory updated most recently are erased. To secure a write cache memory. Note that the data in the write cache memory can also be used as the data in the read cache memory.

  Thereafter, the data transferred from the upper side is stored in the secured write cache memory, and the command end is returned (s27).

  If the lower driver 152 determines in step s24 that the request from the upper side is a read request and matches the contents of the expected database (the LBA and the number of transfer blocks match), the read side driver memory is secured (s28). . Similarly to the above, if there is a free cache memory, this is used as a read cache memory, and if there is no free space, the contents of the cache memory updated most recently are erased to secure the read cache memory.

  Thereafter, based on the prediction database, an expected read request is transmitted to the lower side, and the data is cached in the read cache memory (s29). At this time, instead of caching a large amount of data at a time, the data cache may be divided into a plurality of times. In this case, the remaining read requests are registered in the command queue. By dividing the read request into multiple parts, the cached data can be transferred to the higher-level driver, while the next continuous read data can be cached in parallel with it, and the USB bus usage rate can be expected to improve. .

  Next, FIG. 9 is a flowchart showing the operation when there is a command end interrupt from the lower side.

  First, the lower driver 152 determines whether or not the command end received from the lower side is a command indicating that the data cached in the write cache memory has been written (s31). When the data in the write cache memory has been written, the write cache memory is changed to a read cache memory (s32). The timing for changing the write cache memory to the read cache memory is not limited to this timing. Of course, as described above, it is possible to use the data in the write cache memory as the data in the read cache memory.

  Thereafter, the lower driver 152 determines whether or not the command requires a completion report (transfer) to the upper side (s33). If necessary, the command end is returned to the upper side (s34).

  Further, the lower-level driver 152 refers to the command queue 160 and determines whether there is a queued command (s35). If there is a queued command, it is transferred to the lower side (s36).

  Next, FIG. 10 is a flowchart showing operations at the time of timer interrupt, driver initialization, and driver termination.

  First, FIG. 4A is a flowchart showing a timer interrupt operation. The lower driver 152 starts this operation when the timer expires. The lower driver 152 checks whether data is cached in the write cache memory (s41). If it is cached, a write request is transmitted to the lower side, the data cached in the write cache memory is transferred to the lower side (s42), and the operation ends. If no data is cached in the write cache memory, the operation ends.

  FIG. 5B is a flowchart showing the operation at the end of the driver. This operation is started when the external HDD 2 is disconnected when the PC is shut down. The lower driver 152 transfers the history database to the external HDD 2 or the OS 11 and saves it (s51).

  FIG. 3C is a flowchart showing the operation at the time of driver initialization. This operation is started when the PC 1 is restarted or the external HDD 2 is reconnected. The lower driver 152 reads the history database from the external HDD 2 or the OS 11 and expands it in the RAM to construct the database 157 (s61).

  In the above embodiment, the upper driver 151 and the lower driver 152 are realized and connected to the general-purpose disk driver 502 or the USB mass storage driver 503. However, the USB mass storage driver is replaced with a dedicated driver. Also in the form, the device controller of the present invention can be realized. FIG. 11 is a functional block diagram illustrating an example of replacing the USB mass storage driver with a dedicated driver. In addition, about the structure which is common in FIG. 4, the same code | symbol is attached | subjected and the description is abbreviate | omitted.

  In this example, a USB host controller driver 504, a general-purpose disk driver 502, and a dedicated USB mass storage class driver 171 connected to the application 101 are provided. The dedicated USB mass storage class driver 171 replaces the conventional standard USB mass storage driver (see FIG. 1).

  This dedicated USB mass storage class driver 171 has a built-in cache memory, as in the above embodiment, and caches data in response to read and write requests received from the upper side. The operation of the dedicated mass storage class driver 171 is the same as the operation of the lower side driver shown in FIGS.

  Also in this example, when the application 101 divides data every 64 kB and issues a read / write request, the dedicated USB mass storage class driver 171 caches the data in the cache memory and transfers the data.

  The dedicated USB mass storage class driver 171 does not have an upper limit of the data transfer size of 64 kB, and can process a read / write request having a size larger than 64 kB. Therefore, since the application 101 or the general-purpose disk driver 501 can issue a read / write request without dividing it into 64 kB units, the delay of command and status processing can be reduced, and data transfer can be performed at high speed. Can be.

1-PC
2-External HDD

Claims (4)

Installed in the OS of a personal computer to which peripheral devices are connected,
A device driver arranged on the lower side of software that sequentially transmits a request for writing to the peripheral device by dividing it into a plurality of commands with an upper limit data transfer size,
The personal computer;
A cache memory that caches data corresponding to the write request;
When the device driver receives a write request for the upper limit data transfer size, it predicts that a write request will be continuously issued thereafter, and returns a pseudo command end to each command to the upper side. Data transferred from the upper side is sequentially cached in the cache memory, and a command having a data transfer size larger than the upper limit of the data transfer size for each command divided by the software is issued to transfer the data in the cache memory to the peripheral A control unit that performs processing to transfer to the device;
Device driver to function. Installed in the OS of a personal computer to which peripheral devices are connected,
A device driver arranged on the lower side of software that sequentially sends a read request to the peripheral device by dividing it into a plurality of commands with an upper limit data transfer size,
The personal computer;
A cache memory that caches data corresponding to the read request;
When the device driver receives a read request for the upper limit data transfer size, it is predicted that a read request will be continuously issued thereafter, and the software driver divides the upper limit of the data transfer size per command divided by the software. Issue a command with a large data transfer size, read the data from the peripheral device and cache it in the cache memory, and then cache the data corresponding to the read request command sequentially sent from the upper side in the cache memory A control unit that transfers the data from the cache memory to the higher-order side when
Device driver to function.   The device driver according to claim 1, wherein the control unit performs data transfer with the peripheral device that is a USB mass storage device.   The device driver according to claim 3, wherein the control unit performs data transfer with the peripheral device operating with an OS standard USB mass storage driver.

Images