Date: Sun, 17 Feb 2019 22:18:20 -0700 From: Warner Losh <imp@bsdimp.com> To: "Rodney W. Grimes" <rgrimes@freebsd.org> Cc: Kyle Evans <kevans@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r344243 - head/stand/lua Message-ID: <CANCZdfp8_nS_=hQSrWwTEUzs%2B-hviQwpdQOD6wyGDPDDq0F9wA@mail.gmail.com> In-Reply-To: <201902180341.x1I3fjf5003561@pdx.rh.CN85.dnsmgr.net> References: <CACNAnaEsMxEPVi-qK36d2iW1sy4-MfQFrLbjp4jpEVZHT8vogQ@mail.gmail.com> <201902180341.x1I3fjf5003561@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <kevans@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfp8_nS_=hQSrWwTEUzs%2B-hviQwpdQOD6wyGDPDDq0F9wA>