[PATCH 1/1] Fix bugs determining active VT consoles

[Remco Treffkorn]

On Friday 31 August 2007, Joe Marcus Clarke wrote:
> On Fri, 2007-08-31 at 12:46 -0400, William Jon McCann wrote:
> > On 8/31/07, Joe Marcus Clarke <marcus at freebsd.org> wrote:
> > > On Fri, 2007-08-31 at 12:22 -0400, William Jon McCann wrote:
> > > > On 8/30/07, Joe Marcus Clarke <marcus at freebsd.org> wrote:
> > > > > On FreeBSD, having a process sit in VT_WAITACTIVE can cause kernel
> > > > > panics or unkillable processes that consume 100% of the CPU.  To
> > > > > work around this problem, replace the model where individual
> > > > > threads call VT_WAITACTIVE with a g_timeout model which checks the
> > > > > active VT every second, and queues an event when it changes.
> > > >
> > > > As I said in the other mail, I don't think we want to do this.  Can
> > > > you describe why you think this isn't a FreeBSD kernel bug?
> > >
> > > I missed the other email, sorry.  From my reading of what this ioctl is
> > > supposed to do, it is typically called after activating a given VT to
> > > ensure that the VT is active before proceeding.  It should not be
> > > something a program sits in for long periods of time.
> >
> > According to what or whom?
>
> I read it from Linux Journal:
>
> http://www.linuxjournal.com/article/2783
>
> That made me think it's used more to see if the switch is complete than
> as an event driver.

This article is from 1994! Nowhere does it indicate a problem with 
VT_WAITACTIVE.

How does this relate to FreeBSD and a potential problem there?

Could you please explain what makes you think there is a FreeBSD bug that 
makes VT_WAITACTIVE risky to use, and why you think working around a problem 
is better than fixing it?

Cheers,
Remco
-- 
Remco Treffkorn (RT445)
HAM DC2XT
remco at rvt.com   (831) 685-1201