IoCreateSymbolicLink(&usDosDeviceName, &usDriverName);

Il primo parametro che viene passato ad una routine di gestione degli IRP è un puntatore all'oggetto device-object (cioè l'oggetto che rappresenta la periferica) associata alla richiesta stessa. Ricordiamo che un driver può creare device multipli per cui il primo parametro è necessario per determinare il device che verrà servito dal driver. Il secondo parametro è una struttura IRP. Questa struttura è parzialmente opaca quindi non tutti i membri sono descritti su MSDN.

La prima cosa da fare è chiamare IoGetCurrentIrpStackLocation che ci fornisce la nostra struttura IO_STACK_LOCATION ( abbiamo detto prima cos'è questa struttura). Nel nostro esempio l'unica informazione di cui necessitiamo (e che useremo) è la lunghezza del buffer fornito al driver. Questo parametro si trova nel membro Parameters.Write.Length.  (quanto spazio abbiamo a disposizione per scrivere) 

Per utilizzare un I/O Diretto è necessario appoggiarsi ad una struttura denominata MdlAddress ( Memory Description List) che viene passata al driver dal sottosistema di I/O, tramite la struttura IRP, ogni volta che è necessaria un'operazione di I/O. 

Questa struttura contiene una descrizione degli indirizzi in user-mode e di come sono mappati in indirizzi fisici. Per recuperare l'indirizzo sul quale operare (un puntatore a CHAR in realtà) useremo la funzione, del sottosistema di gestione della memoria, MmGetSystemAddressForMdlSafe.

Questa funzione, richiamata sul membro Irp->MdlAddress, ci darà un Indirizzo Virtuale di Sistema (un puntatore a char) che potremo usare per leggere dal flusso di I/O.

Il ragionamento che stà dietro tutta questa conversione di indirizzi è semplice. Il driver il più delle volte gira in un contesto diverso rispetto a quello del processo che ha avviato la richiesta di I/O. Quindi gli indirizzi virtuali dell'user-mode, durante due context-switch saranno gli stessi ma potrebbero trovarsi in locazioni fisiche diverse dopo diversi context-switch. Ecco perchè ci appoggiamo al sistema operativo, in particolare al sottosistema di gestione della memoria che CONOSCE SEMPRE IL MAPPING (lo fà lui) tra indirizzi logici e fisici di ogni thread.

Una volta recuperato il buffer dal quale leggere, possiamo operare normalmente, ricordandoci di utilizzare SEMPRE funzioni KERNEL e mai funzioni Win32. (Per manipolare le stringhe ad esempio NON VANNO USATE LE FUNZIONI IN str etc)

Questo metodo di operare, Direct I/O, è generalmente usato per buffer di grandi dimensioni che non RICHIEDONO la copia della memoria e la successiva elaborazione. Infatti il Driver ACCEDE DIRETTAMENTE alla memoria (buffer) del processo, che rimane bloccata finchè l'IRP non viene completato. 

BUFFERED I/O 

NTSTATUS Example_WriteBufferedIO(PDEVICE_OBJECT DeviceObject, PIRP Irp)
{
    NTSTATUS NtStatus = STATUS_SUCCESS;
    PIO_STACK_LOCATION pIoStackIrp = NULL;
    PCHAR pWriteDataBuffer;

    DbgPrint("Example_WriteBufferedIO Called \r\n");
    
    /*
     * Each time the IRP is passed down
     * the driver stack a new stack location is added
     * specifying certain parameters for the IRP to the driver.
     */
    pIoStackIrp = IoGetCurrentIrpStackLocation(Irp);
    
    if(pIoStackIrp)
    {
        pWriteDataBuffer = (PCHAR)Irp->AssociatedIrp.SystemBuffer;
    
        if(pWriteDataBuffer)
        {                             
            /*
             * We need to verify that the string
             * is NULL terminated. Bad things can happen
             * if we access memory not valid while in the Kernel.
             */
           if(Example_IsStringTerminated(pWriteDataBuffer, 
                   pIoStackIrp->Parameters.Write.Length))
           {
                DbgPrint(pWriteDataBuffer);
           }
        }
    }

    return NtStatus;
}

Come detto in precedenza, l'idea dello stack e quella di passare i dati verso il basso, di driver in driver, in modo che possano essere accessibili in ogni contesto. 

Un motivo per il quale potrebbe essere usato questo tipo di I/O è quello di voler mappare la memoria in modo che possa essere letta anche a IRQL alti. (la memoria paginabile non è accessibile in DISPATCH_LEVEL e DIRQL LEVEL)

Un altro motivo potrebbe essere quello di voler accedere alla memoria al di fuori del contesto corrente da thread che i driver creano associandoli al processo SYSTEM. 

Gli svantaggi associati a questo metodo sono presto detti. 

-E' necessario allocare memoria non paginabile e copiarci dentro i dati che bisogna processare. Ciò chiaramente determina un overhead durante i processi di lettura e scrittura. Questa è la principale causa che determina l'utilizzo dell'I/O bufferizzato per buffer di piccole dimensioni. 

- E' poco efficiente con i buffer di grandi dimensioni perchè necessita l'allocazione di grandi porzioni di memoria non paginabile. (non scaricabile sul disco e quindi il consumo di memoria è elevato).

Il vantaggio nasce dal fatto che l'intera memoria usata in user-mode non resterà bloccata durante l'operazione come invece accade con il Direct I/O.

Neither Buffered nor Direct ( Nè bufferizzata, nè diretta )

NTSTATUS Example_WriteNeither(PDEVICE_OBJECT DeviceObject, PIRP Irp)
{
    NTSTATUS NtStatus = STATUS_SUCCESS;
    PIO_STACK_LOCATION pIoStackIrp = NULL;
    PCHAR pWriteDataBuffer;

    DbgPrint("Example_WriteNeither Called \r\n");
    
    /*
     * Each time the IRP is passed down
     * the driver stack a new stack location is added
     * specifying certain parameters for the IRP to the driver.
     */
    pIoStackIrp = IoGetCurrentIrpStackLocation(Irp);
    
    if(pIoStackIrp)
    {
        /*
         * We need this in an exception handler or else we could trap.
         */
        __try {
        
                ProbeForRead(Irp->UserBuffer, 
                  pIoStackIrp->Parameters.Write.Length, 
                  TYPE_ALIGNMENT(char));
                pWriteDataBuffer = Irp->UserBuffer;
            
                if(pWriteDataBuffer)
                {                             
                    /*
                     * We need to verify that the string
                     * is NULL terminated. Bad things can happen
                     * if we access memory not valid while in the Kernel.
                     */
                   if(Example_IsStringTerminated(pWriteDataBuffer, 
                          pIoStackIrp->Parameters.Write.Length))
                   {
                        DbgPrint(pWriteDataBuffer);
                   }
                }

        } __except( EXCEPTION_EXECUTE_HANDLER ) {

              NtStatus = GetExceptionCode();     
        }

    }

    return NtStatus;
}