Re: [PATCH] init: make init failures more explicit

2013-10-18 Thread Janne Karhunen
On Fri, Oct 18, 2013 at 11:47 AM, Michael Opdenacker wrote: > This patch proposes to make init failures more explicit. > > Before this, the "No init found" message didn't help much. > It could sometimes be misleading and actually mean > "No *working* init found". Heh, I was just looking at simil

Re: [PATCH] init: make init failures more explicit

2013-10-18 Thread Michael Opdenacker
Hi Geert, On 10/18/2013 11:23 AM, Geert Uytterhoeven wrote: > On Fri, Oct 18, 2013 at 10:47 AM, Michael Opdenacker > wrote: >> + if (ret && ret != -ENOENT) { >> + pr_err("Starting init: %s exists but couldn't execute it\n", > I think it makes sense to also print the value of r

Re: [PATCH] init: make init failures more explicit

2013-10-18 Thread Geert Uytterhoeven
On Fri, Oct 18, 2013 at 10:47 AM, Michael Opdenacker wrote: > + if (ret && ret != -ENOENT) { > + pr_err("Starting init: %s exists but couldn't execute it\n", I think it makes sense to also print the value of ret here. Apart from your -ENOEXEC case, peeking a bit around, it can

Re: [PATCH] init: make init failures more explicit

2013-10-18 Thread Kieran Bingham
Fantastic I've been hurt by this in the past - and this patch would certainly would have helped save some time! -- Kieran On 18 October 2013 09:47, Michael Opdenacker wrote: > This patch proposes to make init failures more explicit. > > Before this, the "No init found" message didn't help much

[PATCH] init: make init failures more explicit

2013-10-18 Thread Michael Opdenacker
This patch proposes to make init failures more explicit. Before this, the "No init found" message didn't help much. It could sometimes be misleading and actually mean "No *working* init found". This message could hide many different issues: - no init program candidates found at all - some init pr