On Thu, 2016-03-24 at 16:01 +0100, Edward Tomasz Napierała wrote:
> On 0324T1609, Alexander Motin wrote:
> > On 24.03.16 15:42, Edward Tomasz Napierała wrote:
> > > On 0324T1032, Jean-Sébastien Pédron wrote:
> > > > On 23/03/2016 18:45, Edward Tomasz Napierala wrote:
> > > > > > So maybe callouts are disabled in this situation. If there
> > > > > > is a way to
> > > > > > detect that, then vt(4) can go back to a "synchronous mode"
> > > > > > where it
> > > > > > refreshes the screen after each typed character, like it
> > > > > > does when ddb
> > > > > > is active.
> > > > >
> > > > > Looks like that's the case: for some reason the callouts
> > > > > don't work.
> > > > > This trivial hack is a (mostly) working workaround:
> > > > >
> > > > > Index: svn/head/sys/kern/kern_cons.c
> > > > > =============================================================
> > > > > ======
> > > > > --- svn/head/sys/kern/kern_cons.c (revision 297210)
> > > > > +++ svn/head/sys/kern/kern_cons.c (working copy)
> > > > > @@ -430,6 +430,7 @@ cngets(char *cp, size_t size, int
> > > > > visible)
> > > > > lp = cp;
> > > > > end = cp + size - 1;
> > > > > for (;;) {
> > > > > + pause("meh", 1);
> > > >
> > > > Could you please explain how this works to me? Does calling
> > > > pause() here
> > > > give a chance to interrupt handlers or other threads of
> > > > running?
> > >
> > > It looks like it allows the callout to run. I've did an
> > > experiment
> > > and added a simple callout that printed something each second;
> > > during
> > > the root mount prompt it doesn't get run unless you type '.',
> > > which
> > > calls pause(9).
> >
> > Kernel threads run with absolute priorities, so if somehow this
> > threads
> > happen to have higher or equal priority then callout thread, or the
> > kernel is built without PREEMPTION, then the last may never be
> > executed
> > until this thread get to sleep or at least call sched_yield().
>
> The callout's td_priority seems to be 40; the thread running the
> prompt
> is 84, so it's lower.
>
> I've just noticed another curious thing, though: when you press
> ScrLk,
> the screen gets immediately refreshed; also, pressing arrows works
> just
> the way it should. In other words, the refresh is broken except for
> the ScrlLk mode, where it works as it should.
Since cngets() is used only by the mountroot prompt and the geli pw
entry, pausing/yielding within the input loop seems like a good idea.
It would allow for things like plugging in a usb device and having it
actually appear without having to enter a '.' several times.
It would be nice if the pause were done with pause_sbt() and a shorter
timeout, maybe a millisecond or even 100uS. Otherwise things like
pasting text at that prompt in a serial console is likely to drop
chars.
Hmmm... speaking of the geli pw prompt... what's the locking situation
there? Will there be any problems calling pause() from that context?
-- Ian
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
