Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 24 Aug 2008 19:50:57 +0000 (UTC)
From:      Ed Schouten <ed@FreeBSD.org>
To:        src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   cvs commit: src/sys/dev/syscons syscons.c
Message-ID:  <200808241951.m7OJp51g049370@repoman.freebsd.org>

next in thread | raw e-mail | index | archive | help
ed          2008-08-24 19:50:57 UTC

  FreeBSD src repository

  Modified files:
    sys/dev/syscons      syscons.c 
  Log:
  SVN rev 182117 on 2008-08-24 19:50:57Z by ed
  
  Make syscons(4) use ttyv0 instead of consolectl as its primary window.
  
  When I was hacking on uart(4) to make it work with the MPSAFE TTY layer,
  I noticed there was a difference between the way syscons and uart work
  with respect to consoles:
  
  - The uart(4) driver sets cn_name to the corresponding ttyu%r node,
    which means init(8) (which opens /dev/console) will have its output
    redirected to /dev/ttyu%r. After /etc/rc is done, it can spawn a getty
    on that device node as well.
  
  - Syscons used a little different approach. Apart from the /dev/ttyv%r
    nodes, it creates a /dev/consolectl node. This device node is used by
    moused and others to deliver their data, but for some reason it also
    acts as a TTY, which shares its stat structure with ttyv0. This device
    node is used as a console (run conscontrol).
  
  There are a couple advantages of this approach:
  
  - Because we use two different TTY's to represent the 0th syscons
    window, we allocate two sets of TTY buffers. Even if you don't use
    /dev/consolectl after the system has booted (systems that don't run
    moused), it seems the buffers are still allocated.
  
  - We have to apply an evil hack to redirect input to /dev/consolectl.
    Because each window (stat) is associated not associated with one TTY,
    syscons solves this by redirecting all input to closed TTY's to
    consolectl.
  
    This means that opening /dev/ttyv0 while in single user mode will
    probably cause strange things to happen with respect to keyboard input
    redirection.
  
  The first patch that I discussed with philip@ turned consolectl into a
  symlink to ttyv0, but this was not a good idea, because in theory we
  would want consolectl to be a simple device node, which contains all the
  `privileged' ioctl()'s. Apart from that, it didn't work, because each
  time /dev/ttyv0 got revoked, moused also lost its descriptor to deliver
  input, which meant you had to plug out/in your mouse to make it work
  again. This version just leaves the consolectl device the way it is. It
  can still be used to write output to ttyv0, but it can no longer receive
  any input.
  
  In my opinion this patch is not a complete solution, but it's already a
  step in the good direction. It would allow us to turn consolectl into a
  special (non-TTY) device node in the far future. It shaves off 15 KB of
  wasted TTY buffer space.
  
  Discussed with: philip
  
  Revision  Changes    Path
  1.462     +6 -11     src/sys/dev/syscons/syscons.c



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