Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 17 Feb 2019 21:11:09 -0700
From:      Ian Lepore <ian@freebsd.org>
To:        rgrimes@freebsd.org, Kyle Evans <kevans@freebsd.org>
Cc:        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:  <e1eaf80774461cba5bbd65caa808d5f7b5848213.camel@freebsd.org>
In-Reply-To: <201902180341.x1I3fjf5003561@pdx.rh.CN85.dnsmgr.net>
References:  <201902180341.x1I3fjf5003561@pdx.rh.CN85.dnsmgr.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2019-02-17 at 19:41 -0800, Rodney W. Grimes 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.
> 
> 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.
> 
> screen clear == evil, unless specifically requested by the user.
> 

Screen clear before drawing the menu makes sense. What I noticed is
that the screen was still clearing even with beastie_disable=YES.

Clearing before prompting for passwords seems like a marginal case...
as Kyle mentioned, you've got to get the screen into a known state so
that not-echoing the typed pw works reliably.

-- Ian




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e1eaf80774461cba5bbd65caa808d5f7b5848213.camel>