> >
> > Sounds to me, this TODO item should be on your TODO list - not in
> kernel
> > sources :-)
> >
>
> Also, that TODO sounds like there's output to userspace that can be
> parsed by a userspace tool. If a tool expects the current format, it
> may
> not be acceptable to change it later.
>
> If the contents of this patch has nothing to do with the TODO, then
> leave it out. It just confuses things.
Steve, you do have a good point here. I am wondering if that is why we should
consider changing the output to match aer_print_error(). The code path to
aer_print_error() is the more common path where not as many platforms support
the cper_print_error() path (firmware first AER). So it is more likely that
any tools written would know how to parse the output from aer_print_error().
It would be good for those tools to support firmware first AER when it becomes
more common. Of course this is purely conjecture. I have no idea if there are
any tools that parse this text output.
Lance
N�����r��y����b�X��ǧv�^�){.n�+����{����zX����ܨ}���Ơz�&j:+v�������zZ+��+zf���h���~����i���z� �w���?�����&�)ߢf��^jǫy�m��@A�a���
0��h���i
