Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 7 Jan 2020 14:19:54 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To:     Petr Mladek <pmladek@suse.com>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
        Benjamin Herrenschmidt <benh@kernel.crashing.org>,
        linux-kernel@vger.kernel.org,
        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH v2] printk: Fix preferred console selection with multiple
 matches
Message-ID: <20200107051954.GA205756@google.com>
References: <2712d7e2fb68bca06a33e2e062fc8e65a2652410.camel@kernel.crashing.org>
 <20191219135053.xr67lybhycepcxkp@pathway.suse.cz>
 <32fde8cd451ea0eaff38108d9f2f2d4a97a43097.camel@kernel.crashing.org>
 <20191220091131.4uifcbudwppjspf4@pathway.suse.cz>
 <20200106051508.GA17351@google.com>
 <20200106102537.nirnfcauqdh4olgv@pathway.suse.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200106102537.nirnfcauqdh4olgv@pathway.suse.cz>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On (20/01/06 11:25), Petr Mladek wrote:
> On Mon 2020-01-06 14:15:08, Sergey Senozhatsky wrote:
> > On (19/12/20 10:11), Petr Mladek wrote:
> > [..]
> > > > > > +enum con_match {
> > > > > > +	con_matched,
> > > > > > +	con_matched_preferred,
> > > > > > +	con_braille,
> > > > > > +	con_failed,
> > > > > > +	con_no_match,
> > > > > > +};
> > > > > 
> > > > > Please, replace this with int, where:
> > > > > 
> > > > >    + con_matched -> 0
> > > > >    + con_matched_preferred -> 0 and make "has_preferred" global variable
> > > > >    + con_braile -> 0		later check for CON_BRL flag
> > > > >    + con_failed -> -EFAULT
> > > > >    + con_no_match -> -ENOENT
> > > > 
> > > > Not fan of using -EFAULT here, it's a detail since it's rather kernel
> > > > internal, but I'd rather use -ENXIO for no match and -EIO for failed
> > > > (or pass the original error code up if any). That said it's really bike
> > > > shed painting at this point :-)
> > > 
> > > Sigh, either variant is somehow confusing.
> > > 
> > > I think that -ENOENT is a bit better than -EIO. It is abbreviation of
> > > "No entry or No entity" which quite fits here. Also the device might
> > > exist but it is not used when not requested.
> > 
> > Can we please keep the enum? Enum is super self-descriptive, can't
> > get any better. Any other alternative - be it -EFAULT or -EIO or
> > -ENOENT - would force one to always look at what is actually going
> > on in try_match_new_console() and what particular errno means. None
> > of those errnos fit, they make things cryptic. IMHO.
> 
> I agree that the enums are more self-descriptive. My problem with it is
> that there are 5 values. I wanted to check how they were handled
> and neither 'con_matched' nor 'con_failed' were later used.

Right, I also saw that not all con_match were used, but I didn't consider
it to be an issue, con_match describes all possible cases (completeness)
but not all of those cases exist in the code.

try_match_new_console() is going to return multiple error codes anyway,
all of which should be handled. Switching to `int' (4 billion possible
values) probably doesn't really help us.

> I though how to improve it. And I ended with feeling that the enum
> did more harm then good. -E??? codes are a bit less descriptive
> but there are only two. The meaning can be explained easily by
> a comment above the function.

I understand it. It's just we don't have appropriate errnos. So instead
of only documenting the logic (because enum is self-documenting), with
errnos we also need to document the return values we check. IMHO.

	-ss