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

[Poul-Henning Kamp]

In message <20040620.105000.106880101.imp at bsdimp.com>, "M. Warner Losh" writes:
>In message: <82937.1087721102 at critter.freebsd.dk>
>            "Poul-Henning Kamp" <phk at 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 at 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.