From owner-svn-src-head@freebsd.org Mon Feb 18 05:18:32 2019 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB50C14F3535 for ; Mon, 18 Feb 2019 05:18:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4E45A7592E for ; Mon, 18 Feb 2019 05:18:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x835.google.com with SMTP id n32so17856303qte.11 for ; Sun, 17 Feb 2019 21:18:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Qk9pHpPd+kQrC79Z3TmbUiq+OBO+OWKv6g25AaCx18k=; b=pc0ErA2uZMQg0o32PNQlGJ0KgQNFYScq09bKkQXc5GGs1RaQ+oeQZL+/KMK8O2Ail3 E3PXW9jst7spwkJxgt1WxXJLT6LouT1jIDGZh9sfEgRY4lqoHRCxIIDdJAiOb/y9K+hz PGZPPRZT8ukj3dekpP2OP1HA7kRU/MlBpBVHClV+NUW2MlW2RayyGvnSpBGywd68rye1 kVub2eNYSTvS+jyHmMmyT04yWow9GoRQ/yvXNdYO7U85/Bul8iZk4s5OfFFUwFrzgMkf LRgBau4Oy+gxlh0DUvJcPLqw17V+EC2pjjPpFzw6s0wiPQlYJYQWVlrkvoBWnGJKJ2Ue ZWIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Qk9pHpPd+kQrC79Z3TmbUiq+OBO+OWKv6g25AaCx18k=; b=iwAWU/lD8Qd3I8f80O3wWoFUi+dt/vgzFJiuc8gAjy8Rk/vxAgicSExsJNdi9a7j8m KGH4UQ0bVuu5qeoblsiawIX83Tis+ELL6UvZ4InyxPOOwM6Ww3kjHgFkv7vxRzETDUAe jKviAvqfmNRQee1Zvay39sW/zlo9pbEkSV51BbSS4QpqG76b+T9yti4L9nzQ983cRT+9 dnZgUykqEgMaGpI3y8DZvQqpq7W1yvXSui0ua538ZCdSLDH9KSipdhiPk97UhBNoM+ZB MktdFGGir7feG5kIWkwG6pfDOEJMfR0cc3NKGup79R+SITENR8Twk5WqzPHZzekDM/3G O3EA== X-Gm-Message-State: AHQUAuaHc9zKrhd7lUGdd+DWNOQkuM1J95XNMs7SE82lQz3TJilNkDNM BvUYE5A6cbi3lMQSQ6eHqctsUHNr8DEdO/9Z2T0pPw== X-Google-Smtp-Source: AHgI3IYdg95C7OgD8S3TWbWz8+jELar++ifFBb0/YaF9JZuDmIBno0J+S/HQqGgg3O3Ge506m0qsn2WB74PjtDH/xpY= X-Received: by 2002:a0c:e98f:: with SMTP id z15mr16251322qvn.115.1550467111786; Sun, 17 Feb 2019 21:18:31 -0800 (PST) MIME-Version: 1.0 References: <201902180341.x1I3fjf5003561@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201902180341.x1I3fjf5003561@pdx.rh.CN85.dnsmgr.net> From: Warner Losh Date: Sun, 17 Feb 2019 22:18:20 -0700 Message-ID: Subject: Re: svn commit: r344243 - head/stand/lua To: "Rodney W. Grimes" Cc: Kyle Evans , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org X-Rspamd-Queue-Id: 4E45A7592E X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.972,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 05:18:33 -0000 On Sun, Feb 17, 2019 at 8:42 PM Rodney W. Grimes < freebsd@pdx.rh.cn85.dnsmgr.net> wrote: > > On Sun, Feb 17, 2019 at 9:00 PM Kyle Evans wrote: > > > > > > Author: kevans > > > Date: Mon Feb 18 02:59:47 2019 > > > New Revision: 344243 > > > URL: https://svnweb.freebsd.org/changeset/base/344243 > > > > > > Log: > > > lualoader: only clear the screen before first password prompt > > > > > > This was previously an unconditional screen clear, regardless of > whether or > > > not we would be prompting for any passwords. This is pointless, > given that > > > the screen clear is only there to put our screen into a consistent > state > > > before we draw the prompts and do cursor manipulation. > > > > > > This is also the only screen clear besides that to draw the menu. > One can > > > now see early pre-loader and loader output with the menu disabled, > which may > > > be useful for diagnostics. > > > > > > Reported by: ian > > > MFC after: 3 days > > > > > > Modified: > > > head/stand/lua/password.lua > > > > > > Modified: head/stand/lua/password.lua > > > > ============================================================================== > > > --- head/stand/lua/password.lua Mon Feb 18 01:57:47 2019 > (r344242) > > > +++ head/stand/lua/password.lua Mon Feb 18 02:59:47 2019 > (r344243) > > > @@ -38,6 +38,7 @@ local INCORRECT_PASSWORD = "loader: incorrect > password > > > -- Asterisks as a password mask > > > local show_password_mask = false > > > local twiddle_chars = {"/", "-", "\\", "|"} > > > +local screen_setup = false > > > > > > -- Module exports > > > function password.read(prompt_length) > > > @@ -80,14 +81,18 @@ function password.read(prompt_length) > > > end > > > > > > function password.check() > > > - screen.clear() > > > - screen.defcursor() > > > -- pwd is optionally supplied if we want to check it > > > local function doPrompt(prompt, pwd) > > > local attempts = 1 > > > > > > local function clear_incorrect_text_prompt() > > > printc("\r" .. string.rep(" ", > #INCORRECT_PASSWORD)) > > > + end > > > + > > > + if not screen_setup then > > > + screen.clear() > > > + screen.defcursor() > > > + screen_setup = true > > > end > > > > > > while true do > > > > > > > I noted in testing that this may look kinda funky if you have neither > > a bootlock password or GELi prompt done by loader(8), but you have a > > loader password. The autoboot text gets blown away by the subsequent > > clear screen. I'd be interesting in feedback as to whether this looks > > odd or how important it is that the autoboot text remains intact, as > > it's an easy fix to retain it. > > Personally I would like to see all screen clears go away, > as they always seem to wipe out the very diagnostic output > that would tell you what went wrong. > Sometimes it's unavoidable. But we have bigger problems here: when you set the console output to something other than default, for example, all messages before we do that (which we necessarily have to do late) are lost. Clearing the screen isn't the problem here: the lack of a dmesg-like history is the problem. > If possible, instead of clearing the screen, we should go to the > bottom and scroll it upwards, drawing new things and scrolling > old things off the top. > This isn't always possible. We don't necessarily know how many lines to scroll, and this will cause things to be overwritten in all serial scenarios, which we get complaints about. > screen clear == evil, unless specifically requested by the user. > Again, the issue is destroying information, not necessarily screen clearing. We did a lot of that traditionally in the FORTH loader too, and weren't always that good about it. I do agree clearing unconditionally at the start is a hassle, especially when you turn off menus. However, with menus, the expectation is to clear the screen so you'd have a clean presentation of the menu. So if we're really worried about error messages, we should implement a history mechanism to get the early printed stuff. It was one of the items that we spoke about while I was doing the Lua work and associated technical debt retirement. There were many other items that were on the list ahead of this feature, and likely still are. Warner