Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp21328425ybl; Mon, 6 Jan 2020 02:27:01 -0800 (PST) X-Google-Smtp-Source: APXvYqwMudtNOZU/bfcBDnzNW+EPaUVUbVu8qXWyvV2tB9zgi6SJc1mLO7VGeZIKZ9+VNYHG2mFC X-Received: by 2002:a9d:4c82:: with SMTP id m2mr4655668otf.199.1578306420955; Mon, 06 Jan 2020 02:27:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578306420; cv=none; d=google.com; s=arc-20160816; b=uadVDRY6vlnJThNcegP+quotW8MmLlbMjKRqIUI/qiRlGzd6cC4tw4hmYy87Ntvux/ te3MP642W7ETZdQ0nIR8xzfahDSq00BM9RYPUH9IDhUhxBrK2x6fDxsFZBnxN5YYwDjt wfJpUhXiIXvO88cmuMqWmB6rQ8QRcT6fWR5lGhOczpqdVA52wSxMijpS8u1cn9w2BSBq H/r3uzxGXuv8O4dR2zXX8dCsUnEDacv7Do07XgtbnO/u1HOXbmHOOKuJtf8eHgYbKIkw 0urA+qUB/83dBQHk6mYdyEhI5aKXgOi/MDouSOvBfoEYfxa8a9pDglOrEoUPyJibp08t noaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=C1Hkv7vpTxLxYjK8PDW0yHW0cgpZfMR8hFIQXitQUdE=; b=c2rFYcujlvNE/bX6o83aEoNBT4OcvdcAL20LgNjncJp52bG9ZlBinP3Uc980E+dD0V v/CyF5peMx7eJbers37GuNcptFqRSjz4kUZZAL1mdPbi9a3YTCeJRacl1XmC7IJtduyg 62QBJxi9DosFg49EXswvJ5Zr8/WVhH4r6K1UyhHiQLkvwcbOE5zuoXgX4K8dqMvquQwR 7ZOZpWv4W1eoIoc4YywNriMrjGdFCZAsS6NnBoW0x9HC2BTtkT8kP0z2aKLojfNWvoYP a0TqHtQSrnIOddSaom65UUxqRddRXLs1e0/yC+Do9wHGJdQZ7VMfm+zWzNLl6xLuxcne zy6A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g1si32321848otj.115.2020.01.06.02.26.48; Mon, 06 Jan 2020 02:27:00 -0800 (PST) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726448AbgAFKZk (ORCPT + 99 others); Mon, 6 Jan 2020 05:25:40 -0500 Received: from mx2.suse.de ([195.135.220.15]:50390 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726351AbgAFKZj (ORCPT ); Mon, 6 Jan 2020 05:25:39 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id F2EFFAF8A; Mon, 6 Jan 2020 10:25:37 +0000 (UTC) Date: Mon, 6 Jan 2020 11:25:37 +0100 From: Petr Mladek To: Sergey Senozhatsky Cc: Benjamin Herrenschmidt , linux-kernel@vger.kernel.org, Sergey Senozhatsky , Steven Rostedt , Linus Torvalds Subject: Re: [PATCH v2] printk: Fix preferred console selection with multiple matches Message-ID: <20200106102537.nirnfcauqdh4olgv@pathway.suse.cz> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200106051508.GA17351@google.com> User-Agent: NeoMutt/20170912 (1.9.0) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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. If you want to keep the enum then please handle the return values by switch(). Or make it clear that all possible return values are handled properly. Best Regards, Petr