/* Actually put the data into the buffer */
while (length && *Message_Ptr) {
/* Because the buffer is in the user data segment, not the kernel
- * data segment, assignment would not work. Instead, we have to
- * use put_user which copies data from the kernel data segment to
- * the user data segment.
+ * data segment, assignment would not work. Instead, we have to
+ * use put_user which copies data from the kernel data segment to
+ * the user data segment.
*/
put_user(*(Message_Ptr++), buffer++);
length--;
switch (ioctl_num) {
case IOCTL_SET_MSG:
/* Receive a pointer to a message (in user space) and set that to
- * be the device's message. Get the parameter given to ioctl by
- * the process.
+ * be the device's message. Get the parameter given to ioctl by
+ * the process.
*/
temp = (char *) ioctl_param;
case IOCTL_GET_MSG:
/* Give the current message to the calling process - the parameter
- * we got is a pointer, fill it.
+ * we got is a pointer, fill it.
*/
i = device_read(file, (char *) ioctl_param, 99, 0);
/* Put a zero at the end of the buffer, so it will be properly
- * terminated.
+ * terminated.
*/
put_user('\0', (char *) ioctl_param + i);
break;
case IOCTL_GET_NTH_BYTE:
/* This ioctl is both input (ioctl_param) and output (the return
- * value of this function).
+ * value of this function).
*/
return Message[ioctl_param];
break;
* kernel's memory segment.
*
* The function's 1st parameter is the tty to write to, because the
- * same function would normally be used for all tty's of a certain
- * type.
+ * same function would normally be used for all tty's of a certain
+ * type.
* The 2nd parameter is a pointer to a string.
* The 3rd parameter is the length of the string.
*
* As you will see below, sometimes it's necessary to use
* preprocessor stuff to create code that works for different
* kernel versions. The (naive) approach we've taken here does not
- * scale well. The right way to deal with this is described in
- * section 2 of
+ * scale well. The right way to deal with this is described in
+ * section 2 of
* linux/Documentation/SubmittingPatches
*/
(ttyops->write)(my_tty, /* The tty itself */
strlen(str)); /* Length */
/* ttys were originally hardware devices, which (usually) strictly
- * followed the ASCII standard. In ASCII, to move to a new line you
- * need two characters, a carriage return and a line feed. On Unix,
- * the ASCII line feed is used for both purposes - so we can not
- * just use \n, because it would not have a carriage return and the
- * next line will start at the column right after the line feed.
+ * followed the ASCII standard. In ASCII, to move to a new line you
+ * need two characters, a carriage return and a line feed. On Unix,
+ * the ASCII line feed is used for both purposes - so we can not
+ * just use \n, because it would not have a carriage return and the
+ * next line will start at the column right after the line feed.
*
* This is why text files are different between Unix and MS Windows.
- * In CP/M and derivatives, like MS-DOS and MS Windows, the ASCII
- * standard was strictly adhered to, and therefore a newline requirs
- * both a LF and a CR.
+ * In CP/M and derivatives, like MS-DOS and MS Windows, the ASCII
+ * standard was strictly adhered to, and therefore a newline requirs
+ * both a LF and a CR.
*/
(ttyops->write)(my_tty, "\015\012", 2);
}
/* Queue of processes who want our file */
DECLARE_WAIT_QUEUE_HEAD(WaitQ);
-
+
/* Called when the /proc file is opened */
static int module_open(struct inode *inode, struct file *file)
{
int i, is_sig = 0;
/* This function puts the current process, including any system
- * calls, such as us, to sleep. Execution will be resumed right
+ * calls, such as us, to sleep. Execution will be resumed right
* after the function call, either because somebody called
* wake_up(&WaitQ) (only module_close does that, when the file
* is closed) or when a signal, such as Ctrl-C, is sent
if (is_sig) {
/* It is important to put module_put(THIS_MODULE) here, because
- * for processes where the open is interrupted there will never
- * be a corresponding close. If we do not decrement the usage
- * count here, we will be left with a positive usage count
- * which we will have no way to bring down to zero, giving us
- * an immortal module, which can only be killed by rebooting
+ * for processes where the open is interrupted there will never
+ * be a corresponding close. If we do not decrement the usage
+ * count here, we will be left with a positive usage count
+ * which we will have no way to bring down to zero, giving us
+ * an immortal module, which can only be killed by rebooting
* the machine.
*/
module_put(THIS_MODULE);