lkml.org 
[lkml]   [2011]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH -v10 0/4] Lock-less list

* huang ying <huang.ying.caritas@gmail.com> wrote:

> On Thu, Jan 20, 2011 at 8:14 PM, Ingo Molnar <mingo@elte.hu> wrote:
> >
> > * huang ying <huang.ying.caritas@gmail.com> 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.

Thanks,

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

\
 
 \ /
  Last update: 2011-01-20 14:09    [W:0.071 / U:1.176 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site