Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp605964ybl; Wed, 29 Jan 2020 06:28:27 -0800 (PST) X-Google-Smtp-Source: APXvYqwfcvwkVcBMRYw8BfltphhBQaDyYFPKdJncD5DHD5DM0NbJbc/xC7lMPOiHmUMkFuwP5Z2K X-Received: by 2002:aca:7244:: with SMTP id p65mr6276594oic.50.1580308106874; Wed, 29 Jan 2020 06:28:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580308106; cv=none; d=google.com; s=arc-20160816; b=kqkFX74HclyI9rYqVsP9eSHgtMNJYmI4CFiJWrHbxQ40ZIVhmhoTQDVfeaGSh9MhYa wHQvY7VoNHbCsbOTrI88Brzt6BdVc6Epj1yTC9azKU6oV1ZQ1y9ogc/BZJW3aj5vwZQY KhWihc4g+z7PkRx7iwTb485686D1ILTMUKGR5stfEUf4xLXvA1mMcDLSvJBTuDtxi+Rh w7VBXuQa3WFH3Yj00rTsUU5LpErf/Du605AqywVOhymYBQDwPvTIh5FYkZWLaJwVvJSO tIpgbetnFsOgRhO1hiXlA16XJtSspNWqldQY1OhO2qBwNBmjTk/EiQN0JnIDfuki9ZUs pKKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:organization:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=elEHgbjhRj5hoeq3z4vlnHRbOxdVj+qXpB0YbyTgcgM=; b=GztewnqyBuSSJy1ub5RSJwTnW/Xe54OPAivGRTnvbArgFwwhvy7sHOylWBG8IvYVNB 6cP1AUH7xHCaEz688Z+HPd6FuNNF5+nu4vOgeX7OqEqqjXYYwhXC1Q8k9Ff/NPFsXyZg fm/JsEw1yP7VjRKbScZWZbnx72ojb+4lbI0mcTOpuj6vr9OvBe+ROwzAGojYWZqzyec1 S1xi3hycvTDxtPxbG+qrXzmz5o8kqK6CH5cN+22hTYwNU2Mcbux/BrhYILTLSkQcMHpL OtHoms5WYwmcTlPGXc/7wKJH0+hcN59qq/Unr6gBZ4/7rWVxHfLAONJIw/q34QYA2dHk KcKQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 105si1181590otu.45.2020.01.29.06.28.13; Wed, 29 Jan 2020 06:28:26 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726694AbgA2OZ7 (ORCPT + 99 others); Wed, 29 Jan 2020 09:25:59 -0500 Received: from mga02.intel.com ([134.134.136.20]:34184 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726261AbgA2OZ6 (ORCPT ); Wed, 29 Jan 2020 09:25:58 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jan 2020 06:25:58 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,378,1574150400"; d="scan'208";a="232457423" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by orsmga006.jf.intel.com with ESMTP; 29 Jan 2020 06:25:56 -0800 Received: from andy by smile with local (Exim 4.93) (envelope-from ) id 1iwoI2-00034u-7w; Wed, 29 Jan 2020 16:25:58 +0200 Date: Wed, 29 Jan 2020 16:25:58 +0200 From: Andy Shevchenko To: Sergey Senozhatsky Cc: Sergey Senozhatsky , Petr Mladek , Steven Rostedt , linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 5/5] console: Introduce ->exit() callback Message-ID: <20200129142558.GF32742@smile.fi.intel.com> References: <20200127114719.69114-1-andriy.shevchenko@linux.intel.com> <20200127114719.69114-5-andriy.shevchenko@linux.intel.com> <20200128051711.GB115889@google.com> <20200128094418.GY32742@smile.fi.intel.com> <20200129134141.GA537@jagdpanzerIV.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200129134141.GA537@jagdpanzerIV.localdomain> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 29, 2020 at 10:41:41PM +0900, Sergey Senozhatsky wrote: > On (20/01/28 11:44), Andy Shevchenko wrote: > > > If the console was not registered (hence not enabled) is it still required > > > to call ->exit()? Is there a requirement that ->exit() should handle such > > > cases? > > > > This is a good point. The ->exit() purpose is to keep balance for whatever > > happened at ->setup(). > > > > But ->setup() is being called either when we have has_preferred == false or > > when we got no matching we call it for all such consoles, till it returns an > > error (can you elaborate the logic behind it?). > > ->match() does alias matching and ->setup(). If alias matching failed, > exact name match takes place. We don't call ->setup() for all consoles, > but only for those that have exact name match: > > if (strcmp(c->name, newcon->name) != 0) > continue; > > As to why we don't stop sooner in that loop - I need to to do some > archaeology. We need to have CON_CONSDEV at proper place, which is > IIRC the last matching console. > > Pretty much every time we tried to change the logic we ended up > reverting the changes. I understand. Seems the ->setup() has to be idempotent. We can tell the same for ->exit() in some comment. Can you describe, btw, struct console in kernel doc format? It will be very helpful! > > In both cases we will get the console to have CON_ENABLED flag set. > > And there are sneaky consoles that have CON_ENABLED before we even > register them. So, taking into consideration my comment to the previous patch, what would be suggested guard here? For a starter something like this? if ((console->flags & CON_ENABLED) && console->exit) console->exit(console); -- With Best Regards, Andy Shevchenko