printk: update changelog

1 files changed, 38 insertions, 45 deletions

diff --git a/printk.patch b/printk.patch
index 8c300f4..f19393a 100644
--- a/printk.patch
+++ b/printk.patch
@@ -6,61 +6,55 @@ state of the system and the connected device. The usual kernel messages are
 mostly human language, targeted at a person reading them. That part of the
 picture works very well since a very long time.
 
-Most machines though, run unattended almost all of their time, and software
-needs, and not humans, to read the kernel messages. Having a machine making
-sense out of human language messages is inefficient, unreliable, or sometimes
-plain impossible to get right. All the useful information about the context
+Most machines run unattended almost all of their time, and software, and not
+humans, need to process the kernel messages. Having a machine making sense
+out of human language messages is inefficient, unreliable, and sometimes
+plain impossible to get right. All the useful information about the context,
 available at the time of creation of the message, is just thrown away. Later,
-consumers of the messages will need to apply magic to guess what the context
-might have been, to interpret the messages.
+the consumers of the messages will need to apply magic to reconstruct what
+the context might have been, to be able to interpret the messages.
 
-This extends printk() to be able to attach arbitrary key/value pairs to the
-log messages, to carry machine-readable data to describe the context of the
+This extends printk() to be able to attach arbitrary key/value pairs to logged
+messages, to carry machine-readable data which describes the context of the
 log message at time of its creation. Users of the log can retrieve, along with
 the human-readable message, a key/value dictionary to reliably identify
 specific devices, drivers, subsystems, classes and types of messages.
 
-- Record-based instead of byte-stream buffer. All records carry proper
-  timestamp, syslog facility, priority in the record header.
+- Record-based instead of the traditional byte-stream buffer. All records
+  carry a 64 bit timestamp, the syslog facility, priority in the record header.
 
 - Records consume almost the same amount, sometimes less memory than
-  the old simple bytes stream buffer with printk_time enabled. The record
-  header is 16 bytes long plus some padding bytes if needed. The old byte
-  stream buffer needed 3 chars for the syslog prefix, 15 char for the
-  timestamp and a newline.
+  the traditional byte-stream buffer with printk_time enabled. The record
+  header is 16 bytes long, plus some padding bytes at the end if needed.
+  The byte-stream buffer needed 3 chars for the syslog prefix, 15 char for
+  the timestamp and a newline.
 
 - The buffer management is based on message sequence numbers. When records
   need to be discarded, the heads move on to the next full record. Unlike
-  the old byte-stream buffer, no old logged lines get truncated or partly
+  the byte-stream buffer, no old logged lines get truncated or partly
   overwritten by new ones. Sequence numbers also allow consumers of the log
-  stream to get notified if any message in the stream they are about to read
+  stream to get notified if any message in the stream, they are about to read,
   gets discarded during the time of reading.
 
 - Better buffered IO support for KERN_CONT continuation lines, when printk()
   is called multiple times for a single line. The use of KERN_CONT is now
-  required; a few places in the kernel need trivial fixes here. The buffering
-  could possibly be extended to per-cpu variables to allow better
-  thread-safety for multiple printk() invocations for a single line.
+  mandatory to use continuation; a few places in the kernel need trivial fixes
+  here. The buffering could possibly be extended to per-cpu variables to allow
+  better thread-safety for multiple printk() invocations for a single line.
 
 - Full-featured syslog facility value support. Different facilities can
   tag their messages. All userspace-injected messages enforce a facility
   value > 0 now, to be able to reliably distinguish them from the
-  kernel-generated messages. Independent subsystems like a baseband
-  processor running its own firmware, or a kernel-related userspace
-  process can use their own unique facility values. Multiple independent
-  log streams can co-exist that way in the same buffer. All share the
-  same global sequence number counter to ensure proper ordering and to
-  allow the consumers of the log to reliably correlate the events
-  from different facilities.
-
-- Subsystems and drivers can easily attach key/value pair dictionaries
-  to any printk() message. Log consumers can extract and recognize
-  these properties reliably, they are not mixed into the human-readable
-  text stream.
+  kernel-generated messages. Independent subsystems like a baseband processor
+  running its own firmware, or a kernel-related userspace process can use
+  their own unique facility values. Multiple independent log streams can
+  co-exist that way in the same buffer. All share the same global sequence
+  number counter to ensure proper ordering and to allow the consumers of the
+  log to reliably correlate the events from different facilities.
 
 - The dev_printk() output is reliably machine-readable now. In addition
-  to the printed message, it creates a log dictionary with the following
-  properties:
+  to the printed plain text message, it creates a log dictionary with the
+  following properties:
     SUBSYSTEM=     - the driver-core subsytem name
     DEVICE=
       b12:8        - block dev_t
@@ -68,23 +62,22 @@ specific devices, drivers, subsystems, classes and types of messages.
       n8           - netdev ifindex
       +sound:card0 - subsystem:devname
 
-- Modern support for multiple concurrent readers of /dev/kmsg. Full read(),
-  seek(), poll() support. Output of message sequence numbers, to allow
-  userspace log consumers to reliably reconnect and reconstruct their state
-  at any given time. After open("/dev/kmsg"), read() always returns all
-  currently available records in the buffer. If only future messages should
-  be read, SEEK_END can be used. In case records get overwritten while
-  /dev/kmsg is held open and not read, or records get faster overwritten
-  than they are read, the next read() will return -EPIPE and the current
-  reading position gets updated to the next available record. The passed
-  sequence numbers allow the log consumer to calculate the amount of lost
-  messages.
+- Support for multiple concurrent readers of /dev/kmsg. Full read(), seek(),
+  poll() support. Output of message sequence numbers, to allow userspace log
+  consumers to reliably reconnect and reconstruct their state at any given
+  time. After open("/dev/kmsg"), read() always returns all currently available
+  records in the buffer. If only future messages should be read, SEEK_END can
+  be used. In case records get overwritten while /dev/kmsg is held open and
+  not read, or records get faster overwritten than they are read, the next
+  read() will return -EPIPE and the current reading position gets updated to
+  the next available record. The passed sequence numbers allow the log consumer
+  to calculate the amount of lost messages.
 
   $ cat /dev/kmsg
   PRIORITY=5
   SEQNUM=0
   TIMESTAMP=0
-  MESSAGE=Linux version 3.3.0+ (kay@mop) (gcc version 4.7.0 20120315 ...
+  MESSAGE=Linux version 3.4.0-rc1+ (kay@mop) (gcc version 4.7.0 20120315 ...
 
   ...