diff --git a/index.html b/index.html index 2d0973d..d48a83f 100644 --- a/index.html +++ b/index.html @@ -2310,9 +2310,9 @@ source tree at Documentation/ioctl-number.txt. 81    /* Actually put the data into the buffer */ 82    while (length && *Message_Ptr) { 83        /* Because the buffer is in the user data segment, not the kernel -84  * data segment, assignment would not work. Instead, we have to -85  * use put_user which copies data from the kernel data segment to -86  * the user data segment. +84         * data segment, assignment would not work. Instead, we have to +85         * use put_user which copies data from the kernel data segment to +86         * the user data segment. 87         */ 88        put_user(*(Message_Ptr++), buffer++); 89        length--; @@ -2366,8 +2366,8 @@ source tree at Documentation/ioctl-number.txt. 137    switch (ioctl_num) { 138    case IOCTL_SET_MSG: 139        /* Receive a pointer to a message (in user space) and set that to -140  * be the device's message.  Get the parameter given to ioctl by -141  * the process. +140         * be the device's message.  Get the parameter given to ioctl by +141         * the process. 142         */ 143        temp = (char *) ioctl_param; 144 @@ -2381,19 +2381,19 @@ source tree at Documentation/ioctl-number.txt. 152 153    case IOCTL_GET_MSG: 154        /* Give the current message to the calling process - the parameter -155  * we got is a pointer, fill it. +155         * we got is a pointer, fill it. 156         */ 157        i = device_read(file, (char *) ioctl_param, 99, 0); 158 159        /* Put a zero at the end of the buffer, so it will be properly -160  * terminated. +160         * terminated. 161         */ 162        put_user('\0', (char *) ioctl_param + i); 163        break; 164 165    case IOCTL_GET_NTH_BYTE: 166        /* This ioctl is both input (ioctl_param) and output (the return -167  * value of this function). +167         * value of this function). 168         */ 169        return Message[ioctl_param]; 170        break; @@ -3151,7 +3151,7 @@ $ 104        int i, is_sig = 0; 105 106        /* This function puts the current process, including any system -107  * calls, such as us, to sleep.  Execution will be resumed right +107         * calls, such as us, to sleep.  Execution will be resumed right 108         * after the function call, either because somebody called 109         * wake_up(&WaitQ) (only module_close does that, when the file 110         * is closed) or when a signal, such as Ctrl-C, is sent @@ -3168,11 +3168,11 @@ $ 121 122        if (is_sig) { 123            /* It is important to put module_put(THIS_MODULE) here, because -124      * for processes where the open is interrupted there will never -125      * be a corresponding close. If we do not decrement the usage -126      * count here, we will be left with a positive usage count -127      * which we will have no way to bring down to zero, giving us -128      * an immortal module, which can only be killed by rebooting +124             * for processes where the open is interrupted there will never +125             * be a corresponding close. If we do not decrement the usage +126             * count here, we will be left with a positive usage count +127             * which we will have no way to bring down to zero, giving us +128             * an immortal module, which can only be killed by rebooting 129             * the machine. 130             */ 131            module_put(THIS_MODULE); @@ -3769,16 +3769,16 @@ tty. 28         * kernel's memory segment. 29         * 30         * The function's 1st parameter is the tty to write to, because the -31  * same function would normally be used for all tty's of a certain -32  * type. +31         * same function would normally be used for all tty's of a certain +32         * type. 33         * The 2nd parameter is a pointer to a string. 34         * The 3rd parameter is the length of the string. 35         * 36         * As you will see below, sometimes it's necessary to use 37         * preprocessor stuff to create code that works for different 38         * kernel versions. The (naive) approach we've taken here does not -39  * scale well. The right way to deal with this is described in -40  * section 2 of +39         * scale well. The right way to deal with this is described in +40         * section 2 of 41         * linux/Documentation/SubmittingPatches 42         */ 43        (ttyops->write)(my_tty,       /* The tty itself */ @@ -3786,16 +3786,16 @@ tty. 45                        strlen(str)); /* Length */ 46 47        /* ttys were originally hardware devices, which (usually) strictly -48  * followed the ASCII standard. In ASCII, to move to a new line you -49  * need two characters, a carriage return and a line feed. On Unix, -50  * the ASCII line feed is used for both purposes - so we can not -51  * just use \n, because it would not have a carriage return and the -52  * next line will start at the column right after the line feed. +48         * followed the ASCII standard. In ASCII, to move to a new line you +49         * need two characters, a carriage return and a line feed. On Unix, +50         * the ASCII line feed is used for both purposes - so we can not +51         * just use \n, because it would not have a carriage return and the +52         * next line will start at the column right after the line feed. 53         * 54         * This is why text files are different between Unix and MS Windows. -55  * In CP/M and derivatives, like MS-DOS and MS Windows, the ASCII -56  * standard was strictly adhered to, and therefore a newline requirs -57  * both a LF and a CR. +55         * In CP/M and derivatives, like MS-DOS and MS Windows, the ASCII +56         * standard was strictly adhered to, and therefore a newline requirs +57         * both a LF and a CR. 58         */ 59        (ttyops->write)(my_tty, "\015\012", 2); 60    } diff --git a/lkmpg-for-ht.html b/lkmpg-for-ht.html index 2d0973d..d48a83f 100644 --- a/lkmpg-for-ht.html +++ b/lkmpg-for-ht.html @@ -2310,9 +2310,9 @@ source tree at Documentation/ioctl-number.txt. 81    /* Actually put the data into the buffer */ 82    while (length && *Message_Ptr) { 83        /* Because the buffer is in the user data segment, not the kernel -84  * data segment, assignment would not work. Instead, we have to -85  * use put_user which copies data from the kernel data segment to -86  * the user data segment. +84         * data segment, assignment would not work. Instead, we have to +85         * use put_user which copies data from the kernel data segment to +86         * the user data segment. 87         */ 88        put_user(*(Message_Ptr++), buffer++); 89        length--; @@ -2366,8 +2366,8 @@ source tree at Documentation/ioctl-number.txt. 137    switch (ioctl_num) { 138    case IOCTL_SET_MSG: 139        /* Receive a pointer to a message (in user space) and set that to -140  * be the device's message.  Get the parameter given to ioctl by -141  * the process. +140         * be the device's message.  Get the parameter given to ioctl by +141         * the process. 142         */ 143        temp = (char *) ioctl_param; 144 @@ -2381,19 +2381,19 @@ source tree at Documentation/ioctl-number.txt. 152 153    case IOCTL_GET_MSG: 154        /* Give the current message to the calling process - the parameter -155  * we got is a pointer, fill it. +155         * we got is a pointer, fill it. 156         */ 157        i = device_read(file, (char *) ioctl_param, 99, 0); 158 159        /* Put a zero at the end of the buffer, so it will be properly -160  * terminated. +160         * terminated. 161         */ 162        put_user('\0', (char *) ioctl_param + i); 163        break; 164 165    case IOCTL_GET_NTH_BYTE: 166        /* This ioctl is both input (ioctl_param) and output (the return -167  * value of this function). +167         * value of this function). 168         */ 169        return Message[ioctl_param]; 170        break; @@ -3151,7 +3151,7 @@ $ 104        int i, is_sig = 0; 105 106        /* This function puts the current process, including any system -107  * calls, such as us, to sleep.  Execution will be resumed right +107         * calls, such as us, to sleep.  Execution will be resumed right 108         * after the function call, either because somebody called 109         * wake_up(&WaitQ) (only module_close does that, when the file 110         * is closed) or when a signal, such as Ctrl-C, is sent @@ -3168,11 +3168,11 @@ $ 121 122        if (is_sig) { 123            /* It is important to put module_put(THIS_MODULE) here, because -124      * for processes where the open is interrupted there will never -125      * be a corresponding close. If we do not decrement the usage -126      * count here, we will be left with a positive usage count -127      * which we will have no way to bring down to zero, giving us -128      * an immortal module, which can only be killed by rebooting +124             * for processes where the open is interrupted there will never +125             * be a corresponding close. If we do not decrement the usage +126             * count here, we will be left with a positive usage count +127             * which we will have no way to bring down to zero, giving us +128             * an immortal module, which can only be killed by rebooting 129             * the machine. 130             */ 131            module_put(THIS_MODULE); @@ -3769,16 +3769,16 @@ tty. 28         * kernel's memory segment. 29         * 30         * The function's 1st parameter is the tty to write to, because the -31  * same function would normally be used for all tty's of a certain -32  * type. +31         * same function would normally be used for all tty's of a certain +32         * type. 33         * The 2nd parameter is a pointer to a string. 34         * The 3rd parameter is the length of the string. 35         * 36         * As you will see below, sometimes it's necessary to use 37         * preprocessor stuff to create code that works for different 38         * kernel versions. The (naive) approach we've taken here does not -39  * scale well. The right way to deal with this is described in -40  * section 2 of +39         * scale well. The right way to deal with this is described in +40         * section 2 of 41         * linux/Documentation/SubmittingPatches 42         */ 43        (ttyops->write)(my_tty,       /* The tty itself */ @@ -3786,16 +3786,16 @@ tty. 45                        strlen(str)); /* Length */ 46 47        /* ttys were originally hardware devices, which (usually) strictly -48  * followed the ASCII standard. In ASCII, to move to a new line you -49  * need two characters, a carriage return and a line feed. On Unix, -50  * the ASCII line feed is used for both purposes - so we can not -51  * just use \n, because it would not have a carriage return and the -52  * next line will start at the column right after the line feed. +48         * followed the ASCII standard. In ASCII, to move to a new line you +49         * need two characters, a carriage return and a line feed. On Unix, +50         * the ASCII line feed is used for both purposes - so we can not +51         * just use \n, because it would not have a carriage return and the +52         * next line will start at the column right after the line feed. 53         * 54         * This is why text files are different between Unix and MS Windows. -55  * In CP/M and derivatives, like MS-DOS and MS Windows, the ASCII -56  * standard was strictly adhered to, and therefore a newline requirs -57  * both a LF and a CR. +55         * In CP/M and derivatives, like MS-DOS and MS Windows, the ASCII +56         * standard was strictly adhered to, and therefore a newline requirs +57         * both a LF and a CR. 58         */ 59        (ttyops->write)(my_tty, "\015\012", 2); 60    }