Re: [PATCH -v2 2/3] ACPI, APEI, Add APEI generic error status print support

[huang ying]

On Wed, Dec 1, 2010 at 7:49 AM, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, 30 Nov 2010 15:00:31 +0800
> Huang Ying <ying.huang@xxxxxxxxx> wrote:
>
>> > However in this case you are avowedly treating the printks as a
>> > userspace interface, with the intention that software be written to
>> > parse them, yes? ÂSo once they're in place, we cannot change them? ÂThat
>> > makes it more important.
>>
>> If my understanding is correct, Linus still don't like the idea of user
>> space hardware error tool.
>
> I'm sure he has no problem with a userspace tool ;) Surely what he doesn't
> like is the proposed kernel interface.
>
>> ÂOn the other hand, if we need this tool, I
>> think printk is not a good tool-oriented hardware error reporting
>> interface for it, because:
>>
>> - There is no overall format or record boundaries for printk, because
>> printk is traditionally for 1-2 lines. ÂThis makes that printk is hard
>> to parse in general.
>
> Well. ÂThese things can be addressed by careful choice of output
> format.
>
>> - Messages from different CPUs may be interleaved.
>
> A single printk() should be atomic.
>
>> - Good error reporting is too verbose for kernel log
>>
>> - printk has no internal priority support, so that high severity errors
>> has no more priority than low severity ones.
>>
>>
>> So my opinion is:
>>
>> - Use printk as human oriented hardware error reporting.
>> - Use another tool oriented interface for user space hardware error tool
>> if necessary.
>>
>> Do you agree? ÂDo you think printk can be used as a good tool-oriented
>> hardware error reporting interface too?
>
> I agree that using printk() is pretty sucky.
>
> However your proposals are waaaaaaaaay too narrow and specific IMO.
> There are several reasons why people want more regular and structured
> kerenl->userspace messaging features. ÂOne such requirement is for
> internationalisation: people want messages to come out in some
> non-language-specific manner so that userspace tools can perform
> catalogue lookups and display the messages in the appropriate language.
> ÂOthers (eg google) want to feed the messages into large-scale
> capturing systems for offline analysis. ÂAnd there are other
> requirements which I forget. ÂSuch a messaging/logging system would
> also incorporate the requirement to log to a persistent store.
>
> So I think that quite a lot of people would be interested in proposals
> for a new and improved kernel->userspace messaging/logging facility.
> But talking about "hardware error reporting" (especially when it covers
> only a teeny subset of possible hardware errors!) is very myopic.
>
> And implementing the broad facility would be a pretty big project. ÂSimply
> chasing down all the stakeholders and understanding their needs would
> turn one's hair grey.
>
> So we're a bit stuck, really. ÂWe would benefit from a quite broad and
> expensive-to-implement messaging/logging system, but we don't even know
> what that will look like yet. ÂYou have a small and highly-specific
> subset of that. ÂIf we merge the subset then it probably will live
> forever even if the broader feature gets written one day, because the
> subset is userspace-visible and adds interfaces which the larger system
> probably won't even implement.
>
> So... Âfor your pretty narrow and specific problem, perhaps using
> printk as a stopgap until somethine better to come along is the correct
> choice.

OK. I will work on the printk based solution, at least as the first step.

Best Regards,
Huang Ying
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/