Update Target Milestone per 3/2006 Deos ADIRU Final EASA audit.

I have a proposed alternate strategy.  Add a new event log API
logProcessMessage() and a execution_history_t ID for "string".  Permit
the event log message to span an even multiple of history entries up
to, say 128 total bytes (which is only 32 words).  For applications
that didn't understand the new message type, they would get some
"bogus" messages, but eventually they'd recover.  

This would be useful not only for logging system messages, but also
for user messages as well.

Sadly, the status monitor GUI would break badly.

Alternatives discussed with Ryan:

Provide mechanism to log arbitrary strings so they are retrievable
(via status monitor, or sysvstream, or whatever).

  Use log*Event()
   Problem:
     1. No good way to provide variable sized records
     Alternatives:
       A. Increase size of log messages (make user specifiable?)
       B. Add a new kind of event log, with variable sized records.
        Problems (both A & B):
          1. Need to bound critical sections.  (Make user
             specifiable?).
          2. User specifiable length would affect kernel stack
             usage. (must call strncpyFromUserMode() inside a
             critical). 
          3. Backward compatibility (or maybe just lots of things
             would have to change).  Kernel, integ tool, regcheck,
             status monitor, GUI (probably).
       B. Add stringStart/StringEnd events and use multiple log
          messages.
        Problems:
          1. Expensive runtime
          2. Ugly implementation in status monitor.
       

  Use a videostream like SMO and log strings.
    Advantages:
      Might be able to make available early in boot up process.
      Only sysvstream needs updating.
    Problem:
      1. If not trapping to kernel, then interleaving possible.
      2. If trapping to kernel, then need bound critical sections and
         has kernel stack size issue.
      3. If non debug only, then videostream needs to be in kernel.
         Alternative:
           A. Use only strings.
             Problem:
                1. Probably would need ItoA and some minimal other
                   ANSI functions. 

One solution often proposed for this is to just update the image mapping code to use the kernel video stream.  One problem with that solution is that the kernel's video stream is in kernel memory, and thus is not writable by the image mapping code which runs in user mode.

CCB visited this PCR on 2010-02-03

CCB visited this PCR on 2010-02-25.

CCB 2 visited this PCR on  2010-03-31

CCB visited this PCR on 2010-05-11

CCB 2 visited this PCR on 2010-09-30.

CCB visited this PCR on 2010-12-17.

CCB visited this PCR on 2011-03-07

CCB visited this PCR on 2011-04-11

CCB2 visited this PCR on 2011-05-16

CCB visited this PCR on 2011-08-17

CCB 2 visited this PCR on 2011-11-04

CCB visited this PCR on 2012-01-31

CCB visited this PCR on 2012-05-15

CCB 2 visited this PCR on 2012-06-08

CCB visited this PCR on 2012-08-24

CCB visited this PCR on 2012-09-07

CCB visited this PCR on 2012-09-17

CCB visited this PCR on 2012-11-19

CCB visited this PCR on 2012-11-26

CCB visited this PCR on 2013-02-12

CCB visited this PCR on 2013-03-18

CCB visited this PCR on 2013-05-15

CCB visited this PCR on 2013-07-19

CCB visited this PCR on 2013-11-15

CCB 2 visited this PCR on 2014-05-20

CCB visited this PCR on 2014-07-14

CCB 2 visited this PCR on 2014-11-11

CCB visited this PCR on 2014-11-17

CCB visited this PCR on 2016-04-18

CCB visited this PCR on 2016-06-20

CCB visited this PCR on 2017-02-01-59501

(In reply to alarson from comment #3)
> ...
>        B. Add stringStart/StringEnd events and use multiple log
>           messages.
>         Problems:
>           1. Expensive runtime
>           2. Ugly implementation in status monitor.

I'm warming to "B".  A slight variation would be to have a new event
type binary_data and new API:


  logProcessEventData(void *data, size_t size)
    for each word "i" of data
      1. System::processHistory()->logEvent(binary_data, data[i]).

Since MAX_KERNEL_FILE_NAME_LENGTH is 32 bytes, this is only 8 event
log entries for the "file not found" file name.

Note that "process" in logProcessEvent() means "system wide event log
for process creation/deletion".  This means that the thread handle
logging the binary data would be unavailable unless we combine the
thread handle's index with the exception id, or the core index.
Having the thread handle of the thread logging a process event would
be a good enhancement either way.

Adding a similar capability to the system event log (i.e., the
"scheduler" log) would be harder because it has 3 word entries, so I'm
proposing we NOT add a logSystemEventData(), or if we did, we'd expand
the log to four words.

The image code would change from:

  logProcessEvent(no_such_partition);

to:

  logProcessEvent(no_such_partition);
  logProcessEventData(filename, strlen(filename);

CCB visited this PCR on 2017-06-28-69227

CCB visited this PCR on 2017-07-06-58325

CCB visited this PCR on 2021-03-26-57787

CCB visited this PCR on 2021-04-05-59141

CCB visited this PCR on 2023-08-14-64795

This is a desired feature that should be included in an upcoming release if time allows.  It is being taken off of HOLD for consideration for Kismet.

CCB visited this PCR on 2024-08-30-49739