> >
> > 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��������+%������w��{.n�����{�����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
