Re: [REVIEW] move tty lock/initial up in the stack

From: Poul-Henning Kamp (phk_at_phk.freebsd.dk)
Date: 06/20/04

  • Next message: Marcel Moolenaar: "Re: [REVIEW] move tty lock/initial up in the stack" 
    To: "M. Warner Losh" <imp@bsdimp.com>
Date: Sun, 20 Jun 2004 19:37:55 +0200

    In message <20040620.105000.106880101.imp@bsdimp.com>, "M. Warner Losh" writes:
    >In message: <82937.1087721102@critter.freebsd.dk>
    > "Poul-Henning Kamp" <phk@phk.freebsd.dk> writes:
    >: In an ideal world the hardware driver would be reduced to just that,
    >: a few simple primitives, "start", "config", "open", "close" and a
    >: backcall "rint" with received data and modem status changes. This
    >: is not too unlike what Marcel have done with uart(4)
    >
    >I guess I'm curious how the tty/cua split would be done in this
    >scheme.

    It falls out quite naturally. The tty/cua split is a software
    abstraction only, the hardware doesn't know.

    >: The major difference is that serial ports are rapidly headed into
    >: the sunset whereas disks are very much a hot topic.
    >
    >I suspect that the decline will last for a long time. Many of the usb
    >devices that I've seen are really usb to rs232 to thing, so I suspect
    >that it is a case of 'Serial ports are dead, long live the serial
    >ports'

    Right, but the days of one FreeBSD box with 64 modems are over.

    We're typically talking less than a handful serial ports per machine
    and only seldom with anything approaching full bw trafic.

    >: Currently I see two ways to get ptys out form under giant:
    >:
    >: 1) write an entirely new pty driver which is totally separate
    >: from the rest of the tty code (We don't need slip/ppp/netgraph
    >: support on ptys anyway).
    >:
    >: 2) clean up the tty code enough that the pty can be deGiantized,
    >: paving the road for the rest of the tty drivers to get the
    >: same treatment, should somebody else care enough.
    >

    I like what Marcel has done with uart(4), it's pretty close to what
    I would have done, but bruce has raised some valid performance
    concerns regarding the interrupt performance etc.

    I think the way I see it right now, a serial port should not have
    a cdevsw{} at all, all that stuff should happen in the generic
    layer.

    Right now, I'm trying to get to the point where I can use ttyread()
    and ttywrite() in sio(4) (and subsequently all other drivers). The
    major things in the way of this right now is the lock/init and
    cua/tty processing in sio and the absense of a tty_detach() (I have
    a partial patch for that).

    (Sounds like the disk mini-layer all over doesn't it ?)

    The other weird detail is the slip/ppp/netgraph line disciplines
    which really doesn't want to be linedisciplines but just want to
    get access to the serial port. Finally there is the console thing
    which is a real mess seen from any layering point of view.

    So I guess what I really would like to see is an API for hooking
    a serial port into the kernel, a multiplex at that level where
    SLIP, PPP, netgraph and TTY can grab hold of a port. Consoles and
    kernel debuggers are slightly special but go at the same level.
    (We might want to have a poll-facility which calls all the interrupt
    routines when we are in a debugger that way the hw-drivers might
    be less magic)

    The major trouble in doing anything about this is testing all the
    non-uart(4) hardware drivers.

    More unknowns than knowns at this point.

    >Are you looking for help on the latter?

    I'm always looking for help :-) the problem is that I'm not sure
    I know with what in this case. 

    -- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
  • Next message: Marcel Moolenaar: "Re: [REVIEW] move tty lock/initial up in the stack"

    Relevant Pages

    • Re: Boot Hang - mmotm 090716 - serial 8250 irq flags support
      ... just lost remote access via virtual serial port] during boot on HP ... Is your virtual serial port the console? ... CPU: L2 Cache: 1024K ... ACPI: bus type pci registered ...
      (Linux-Kernel)
    • Re: dead console
      ... Subject: dead console ... serial port to the serial port of the 3000's console, ... To join/leave the list, search archives, change list settings, * ...
      (comp.sys.hp.mpe)
    • SUMMARY: serial console port access on Sun Fire X2200 M2 running Solaris 10 x86 and x2100
      ... Redirecting Solaris Output to the Serial Port ... ***From Sun Fire X2200 M2 Server Operating System Installation Guide ... Note - To redirect the server output to the console during OS ...
      (SunManagers)
    • Re: Adding a normal serial console to a Power5 520
      ... you should really talk to IBM ... AIX configured the console to go out /dev/vty0... ... console on the serial port to use a console. ... maybe serial terminals are ...
      (comp.unix.aix)
    • Mysterious system freeze-ups on my consoles...
      ... I can't get into the debugger, or do anything at all from the console, ... connection, and it has definitely happened when I've been connected ... over dial-in PPP via a serial port, and more recently I believe I've ... regularly viewing Google with lynx going off the top line to the input ...
      (freebsd-hackers)