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

[Ingo Molnar]

* 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.

Thanks,

	Ingo
--
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/