Tasks:

See coding tasks below.

Resolve parse_rtas_event problem.

Test on SLES 10.
Test on SLES 11.
[Jim has coded a little build-time smoke test -- a program that calls
some of the functions in the v29_compatibility API.  This needs expansion
to cover more functions and to do some run-time testing.]

Document what we're delivering.

Is SLES 9 build environment OK, or do we need SLES 10?

Incompatibilities:

Event type SL_TYPE_APP is not supported, since there's no such event
type in v1+.  [Remedy: Add SL_TYPE_APP support in v1.1.]

[Add per-type incompatibilities.]

Repair actions in v1 are quite different from repair events in v0.2.9:
- v1 repair actions are not events per se.  This has implications for
event queries and listings, at least.  It also may mean that a repair
action and a "real" event may have the same ID number, which wouldn't
happen in 0.2.9.
- v1 repair action doesn't have an event type.
[We currently fake that by using a query to get a list of all events
that ref that repair, and using the type of the first event.]
- v1 repair action doesn't have a list of repaired events.
[We build it using the above query.]

Coding tasks:

Code cleanup:
- Copy over rtas_event and rtas_event_len, encl event_len and event (Jim)
- Code review
- Consistent error reporting
	- Convert printfs.
> 
> 1. The list of referenced API include:
> servicelog_open	CODED
> servicelog_query	(Brad)
- Need to return matched repair actions as well as regular events.

> servicelog_query_close	(Brad)
> servicelog_get_event	CODED
> servicelog_error	CODED
> servicelog_close	CODED
> 
> 2. The list of referenced struct include:
> struct sl_header	OK
> struct sl_ppc64_callout	OK
> struct sl_repair	OK
> struct servicelog	OK
> struct sl_query	(Brad)
> struct sl_ppc64_rtas	OK
> struct sl_ppc64_encl	OK
> struct sl_os		OK
> struct sl_app		not supported: no such v1+ event type

Note that sl_notify is not listed.

There's still some to do on the sl_notify API:
- Finish servicelog_notify_add	(Jim)
> 
> 
> 3. The command line we use in our code are:
> servicelog_notify --query --command="<command path>"
> servicelog_notify --remove --id=<registered id>
> servicelog_notify --add --command=<command path> --type="os|app|ppc64_encl| ppc64_rtas" --severity=1 --repair_action=all --serviceable=all --method=num_arg

Need to modify servicelog_notify command to:
- recognize v0.2.9 options, and build an appropriate match string
- support --modify option?
- print using v0.2.9 format: See v0.2.9 servicelog_print_notification_tool()
vs. v1 servicelog_notify_print()
  - Requires parsing notify->match

Need to modify notification mechanism to create notifications for repair
events, if it doesn't already.

> servicelog_manage --status

Port servicelog_manage -- at least --status and --truncate -- from v0.2.9

> 
> 4. The command line we use in our test:
> servicelog_manage --truncate events --force
> servicelog --type=ppc64_rtas -v

If we can't tell from the args whether they want v0.2.9 or v1+ output,
provide v0.2.9.

> log_repair_action -q -t ppc64_rtas -l <Location>

Repair actions are trouble.  See above.  But at least the v0.2.9
version of the command REQUIRES a -t option while v1 doesn't support -t.

> 
> an example of test case:
> /etc/init.d/rtas_errd stop
> servicelog_manage --truncate events --force
> rtas_errd -df /home/yang/denali3/event_test_instruction/v6_predictive_cpu_failure
> (See attached file: v6_predictive_cpu_failure)
> 
> servicelog --type=ppc64_rtas -v
> ...
> << Callout 2 >>
> Priority            L
> Type                16
> Repair Event Key:   0
> Procedure Id:       n/a
> Location:           U787E.001.0654321-P1
> FRU:                80P5642
> Serial:             YL30F4148008
> CCIN:               261C



TODO After initial 1.2 release:
- bpeters: lsl: add_data.c: Add ability to remove rows of data from the additional_data tables, then make sure 
this is called from event_delete.  Can then remove the INSERT 'OR REPLACE' keyword 
from the add_data insert functions.



