Date: Sun, 20 Jun 2004 19:37:55 +0200 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: "M. Warner Losh" <imp@bsdimp.com> Cc: arch@freebsd.org Subject: Re: [REVIEW] move tty lock/initial up in the stack Message-ID: <90778.1087753075@critter.freebsd.dk> In-Reply-To: Your message of "Sun, 20 Jun 2004 10:50:00 MDT." <20040620.105000.106880101.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?90778.1087753075>