Messages in this thread |  | | | Date | Thu, 20 Jan 2011 15:11:43 +0100 | | From | Ingo Molnar <> | | Subject | Re: [PATCH -v10 0/4] Lock-less list |
| |
* Borislav Petkov <bp@alien8.de> wrote:
> + Tony. > > On Thu, Jan 20, 2011 at 02:06:25PM +0100, Ingo Molnar wrote: > > > > * 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. > > True story. And yet google folk still do that, unfortunately: > https://lkml.org/lkml/2011/1/10/419
I wouldnt worry about that too much - such uses are extremely isolated.
If we give RAS functionality that gives the limited capabilities of /dev/mcelog and much more then the migration path is clear towards the superior solution.
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/
|  |