Re: [PATCH -v10 0/4] Lock-less list

[huang ying]

On Thu, Jan 20, 2011 at 9:06 PM, Ingo Molnar <mingo@xxxxxxx> wrote:
>
> * huang ying <huang.ying.caritas@xxxxxxxxx> wrote:
>
>> On Thu, Jan 20, 2011 at 8:14 PM, Ingo Molnar <mingo@xxxxxxx> wrote:
>> >
>> > * huang ying <huang.ying.caritas@xxxxxxxxx> wrote:
>> >
>> >> > But will all that stuff be accepted? Please stop sending infrastructure bits and
>> >> > focus on your larger RAS picture, once you have consensus on that from all
>> >> > parties involved, then, and only then, does it make sense to submit everything,
>> >> > including infrastructure.
>> >>
>> >> I am not sending hardware error reporting infrastructure. ÂAs far as I know, Linus
>> >> and Andrew suggest to use printk for hardware error reporting. ÂAnd now, I just
>> >> try to write APEI driver and reporting hardware error with printk. ÂIs it
>> >> acceptable? ÂDo you have some other idea about hardware error reporting?
>> >
>> > Erm, how could you possible have missed the perf based RAS daemon work of Boris,
>> > which we've pointed out about half a dozen times already?
>>
>> Even if there is some other hardware error reporting infrastructure
>> such as perf based, I think we still need printk too. After all, as
>> Linus pointed out, printk is the most popular error reporting
>> mechanism so far. Do you think so?
>
> Of course, that's why the upstream EDAC code uses printk too. In fact it does all
> sorts of in-kernel decoding to make the printk output more useful - the /dev/mcelog
> method of pushing all decoding to user-space is fundamentally flawed.
>
> So yes, printk is the primary output channel and having a readable printk output
> pretty much overrides any other concern.
>
> But that is not what you are doing. I get the impression that you are using printk
> as an _excuse_ to not have to work with the RAS people and run some parallel
> framework so that you do not have to work with them or listen to them. It is rather
> counter-productive. Working together is useful.

No.  I am not working on some other hardware error reporting framework
now.  I just want to make printk works better for hardware error
reporting.  For example, printk is not NMI-safe yet, so I need
lockless list and memory allocator to record the information in NMI
handler and printk them later.  And maybe in the future, we can make
printk NMI safe with similar method.  I think there is no
contradiction between my work and other RAS people's work.

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/