log_data() is probably only used by tests, so there's no race problem
there. But log_message() may be used on the main thread's messaging,
which could cause a race condition.

Helps opendcdiag#153.

Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>

This merges the two functions for the most part and makes them use a
single write() call to write the content, minimising the race condition
in logging platform messages.

Unfortunately, it looks like the race condition remains inside the Linux
kernel now. The strace shows:

[pid 377003] write(8, "BPlatform issue: I> This is an i"..., 86 <unfinished ...>
[pid 377005] write(8, "BPlatform issue: I> This is an i"..., 85 <unfinished ...>
[pid 377001] write(8, "BPlatform issue: I> This is an i"..., 84 <unfinished ...>
[pid 376999] write(8, "BPlatform issue: I> This is an i"..., 86 <unfinished ...>

But in at least one run, I got the output:

    - { level: info, text: 'Platform issue: I> This is an informational platform message from CPU 4 (1726088530)BBPlatform issue: I> This is an informational platform message from CPU 6 (1707520692)BBPlatform issue: I> This is an informational platform message from CPU 3 (1368564819)' }
    - { level: info, text: 'Platform issue: I> This is an informational platform message from CPU 2 (1799845445)' }

This was done with a modified self test to print an extra random number so the messages would have different lengths, showing the problem. Fixes opendcdiag#153.

Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>

log_platform_message() is not thread-safe. See opendcdiag#153, which is closed as
"won't fix".

Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>

This merges the two functions for the most part and makes them use a
single writev() call to write the content.

This was originally done to fix opendcdiag#153, but that fails because the Linux
kernel does not guarantee atomicity of write() calls and I wouldn't care
to make a guess what other OSes do. If we want to have
log_platform_message() be thread-safe, we'll need to insert a mutex.

Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>

This merges the two functions for the most part and makes them use a
single writev() call to write the content.

This was originally done to fix opendcdiag#153, but that fails because the Linux
kernel does not guarantee atomicity of write() calls and I wouldn't care
to make a guess what other OSes do. If we want to have
log_platform_message() be thread-safe, we'll need to insert a mutex.

Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>

log_platform_message() is not thread-safe. See #153, which is closed as
"won't fix".

Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>

This merges the two functions for the most part and makes them use a
single writev() call to write the content.

This was originally done to fix opendcdiag#153, but that fails because the Linux
kernel does not guarantee atomicity of write() calls and I wouldn't care
to make a guess what other OSes do. If we want to have
log_platform_message() be thread-safe, we'll need to insert a mutex.

Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>