The rule of thumb is to include the headers we are the direct user of.
In particular, if we need an atomic API, we include <linux/atomic.h>.
On the other hand we should not use headers for no reason. In particular,
if we are not doing any IRQ job, why is the <linux/irq.h> included?
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Since The length of the message buffer is BUF_LEN. When writing the
BUF_LEN length of the string it will overwrite the last character
(usually it is '\0' from the initialization). And, because the read
operation uses the character in the message buffer ('\0') to stop the
read loop. It will cause the read operation will read out of the
message buffer when the length parameter of read() is not lower than
or equal to BUF_LEN. So add one more byte space to avoid this problem.
Since Linux v3.14, the read, write and seek operations of "struct file" are
guaranteed for thread safety [1][2]. This patch added an explanation.
Here are the potential problems:
chardev.c:
- Move the "msg_ptr" pointer into the read function to remove unnecessary usage.
- List the clear states of "already_open" by using mnemonic enumeration.
chardev2.c:
- The "buffer" in the write function is user space data. It cannot use in the
kernel space.
- Reduce the redundant type transformation.
- List the states of "already_open". Same as chardev.c.
[1] https://lore.kernel.org/lkml/20140303210359.26624.qmail@science.horizon.com/T/#u
[2] 9c225f2655
In file {chardev,chardev2,sleep}.c, the variable to determine
the exclusive access was of integer type, which led to race
condition.
This patch rewrote the above with atomic CAS respectively
to eliminate the race.
Close#93
The device file create in this example is "chardev".
So input command "sudo cat /dev/chardev" will get a valid message
"I already told you %d times Hello world!"
