{"id":366,"date":"2008-10-01T16:43:42","date_gmt":"2008-10-01T16:43:42","guid":{"rendered":"https:\/\/driverentry.com.br\/en\/2008\/10\/01\/buffered-direct-or-neither\/"},"modified":"2026-07-29T18:52:02","modified_gmt":"2026-07-29T18:52:02","slug":"buffered-direct-or-neither","status":"publish","type":"post","link":"https:\/\/driverentry.com.br\/en\/2008\/10\/01\/buffered-direct-or-neither\/","title":{"rendered":"Buffered, Direct or Neither"},"content":{"rendered":"
\"\"<\/a><\/div>\n

In the last post<\/a> I gave a brief introduction about some points regarding virtual memory that I consider to be the most relevant to driver developers. With that small load of knowledge, it will be simpler to explain the differences between the methods of transferring data between applications and drivers, as well as other issues, such as interrupt servicing, memory mapping and execution context.<\/p>\n

If we think in a very simplified way (and I do mean simplified), drivers are basically the modules that extract data from devices and make it available to applications and vice versa. From this point of view, it really does seem that writing drivers is easy. It even looks like a way of doing a memcpy<\/em> from software to hardware. Today we will see a little about the ways a driver can choose to do this data transfer.<\/p>\n

Using a system Buffer<\/h3>\n

The first method is the so-called Buffered I\/O<\/strong>. This method uses a system buffer to transfer data between the application and the driver. When an application calls the WriteFile<\/a> function passing the data to be sent to the driver, the I\/O Manager makes a copy of the application’s data into a system buffer. But what is a system buffer?<\/strong> It is an allocation in System Space<\/em> that was made in Kernel-Mode<\/em>, and for that reason, is accessible in any process context. We already talked about this in the last post<\/a>.<\/p>\n

\n
BOOL WINAPI WriteFile(<\/pre>\n
  __in         HANDLE hFile,<\/pre>\n
  __in         LPCVOID lpBuffer,<\/pre>\n
  __in         DWORD nNumberOfBytesToWrite,<\/pre>\n
  __out_opt    LPDWORD lpNumberOfBytesWritten,<\/pre>\n
  __inout_opt  LPOVERLAPPED lpOverlapped<\/pre>\n
);<\/pre>\n<\/div>\n
The I\/O Manager gets the size of the buffer to be allocated from the nNumberOfBytesToWrite<\/strong> parameter, then performs a non-paged memory allocation and copies the data that is in User Space<\/em> to System Space<\/em>. If you are slipping on the terms System Space<\/em>, User Space<\/em> and types of memory allocation, take a read of this post<\/a> so that things become less obscure for you.<\/p>\n
In the driver, the pointer to this buffer is obtained from the IRP and its size is obtained from the IRP’s stack location. Cool, but what is an IRP?<\/a> Take a look at this mini example below to get an idea, or you can see the example used in this other post<\/a> that also uses the Buffered<\/em> method to send and receive strings from an example driver.<\/p>\n
\n
\/\/-f--> Handler routine for IRP_MJ_WRITE.<\/span><\/pre>\n
\/\/      Example of obtaining the system buffer<\/span><\/pre>\n
\/\/      allocated by the I\/O Manager in the Buffered method<\/span><\/pre>\n
 <\/pre>\n
NTSTATUS<\/pre>\n
OnDispatchWrite(__in PDEVICE_OBJECT pDeviceObj,<\/pre>\n
                __in PIRP           pIrp)<\/pre>\n
{<\/pre>\n
    PIO_STACK_LOCATION  pStack;<\/pre>\n
    PVOID               pBuffer;<\/pre>\n
    ULONG               ulLength;<\/pre>\n
 <\/pre>\n
    \/\/-f--> Gets the current stack location of the IRP<\/span><\/pre>\n
    pStack = IoGetCurrentIrpStackLocation();<\/pre>\n
 <\/pre>\n
    \/\/-f--> Here we get the pointer to the buffer<\/span><\/pre>\n
    pBuffer = pIrp->AssociatedIrp.SystemBuffer;<\/pre>\n
 <\/pre>\n
    \/\/-f--> Here the size of the buffer<\/span><\/pre>\n
    ulLength = pStack->Parameters.Write.Length;<\/pre>\n
 <\/pre>\n
    ...<\/pre>\n
}<\/pre>\n<\/div>\n
In read operations, the method is very similar, but although in this case the I\/O Manager also makes the allocation in non-paged memory, it does not make any copy into the system buffer. The system buffer is received by the driver also through pIrp->AssociatedIrp.SystemBuffer<\/strong>, but its size is obtained from pStack->Parameters.Read.Length<\/strong>. The driver will fill the buffer with the data coming from the device, and the I\/O Manager will copy the buffer from System Space<\/em> to User Space<\/em> when the IRP is completed, filling the application’s buffer.<\/p>\n
Whoa, whoa! As far as I know, drivers normally complete IRPs in an arbitrary context, which means “only God knows in which process context”<\/em>. It is fine if the driver writes to a system buffer, which is valid for any process, but the application’s buffer is in User Space<\/em> and is only accessible in the context of its own process. How would the I\/O Manager copy the system buffer to the application buffer in an arbitrary context?<\/strong> Wow, that really was an excellent question. I do not think even I would have imagined such a good question. IRPs can be handled both synchronously and asynchronously. The I\/O Manager knows how the IRP was processed, and in the synchronous case, the I\/O Manager is already in the context of the process that made the request, and in this case it has access to both buffers, since the I\/O Manager runs in Kernel-Mode<\/em>. When the IRP is handled asynchronously, the I\/O Manager queues an APC<\/strong> (Asynchronous Procedure Call<\/a>), which is an asynchronous call executed in the context of a given thread. That thread is precisely the thread that started the operation, and which therefore will be in the right process context to access the application’s User Space<\/em>.<\/p>\n
\n
BOOL WINAPI ReadFile(<\/pre>\n
  __in         HANDLE hFile,<\/pre>\n
  __out        LPVOID lpBuffer,<\/pre>\n
  __in         DWORD nNumberOfBytesToRead,<\/pre>\n
  __out_opt    LPDWORD lpNumberOfBytesRead,<\/pre>\n
  __inout_opt  LPOVERLAPPED lpOverlapped<\/pre>\n
);<\/pre>\n<\/div>\n
In the call to the ReadFile<\/a> function, the nNumberOfBytesToRead<\/em> parameter indicates the size of the buffer that the application is offering to the driver. The driver receives this value as the maximum number of bytes that can be returned to the application. Assuming the application has offered 1000 bytes, the I\/O Manager allocates 1000 bytes and passes the buffer to the driver. Let us suppose the driver has only 500 bytes to return to the application; in this case, the I\/O Manager will have to copy to the application buffer only 500 of the 1000 allocated bytes. The I\/O Manager receives this value through the pIrp->IoStatus.Information<\/strong> field, which is filled in by the driver before the IRP is completed. This way, the I\/O Manager copies only the valid bytes from the system buffer to the application buffer. This same value is returned to the application through the lpNumberOfBytesRead<\/em> parameter.<\/p>\n
Using non-paged memory to hold the system buffer assures us that the pages will not be removed from RAM by paging. This allows the page to be accessed even from threads running at a high priority level. However, the Buffered<\/em> method is indicated only for small data movements. Imagine that an application wants to write 10 MB all at once. The I\/O Manager would have to make a System Space<\/em> allocation of 10 MB of non-paged memory, which would not be at all appropriate, since non-paged memory is a scarce resource. If the I\/O Manager manages to make the allocation, it will still have to make a 10 MB copy from the application buffer to the system buffer. This would even work, but we would have serious performance problems. In this case, the most appropriate thing would be to use the method seen next.<\/p>\n
Locking the Application’s memory<\/h3>\n
In the method called Direct I\/O<\/strong>, as the name already suggests, the driver accesses the application’s memory pages directly without using an intermediate buffer. This way, the I\/O Manager does not make an allocation in non-paged memory and also does not have to do the BPL-BPC (Buffer over there – Buffer over here<\/em>). Instead, the I\/O Manager tests the memory pages that make up the buffer offered by the application, creates an MDL<\/strong> and locks the memory pages in RAM. Whoa! Hold on there my friend, let us go slowly!<\/strong><\/p>\n