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

[M. Warner Losh]

In message: <90778.1087753075 at critter.freebsd.dk>
            "Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
: It falls out quite naturally.  The tty/cua split is a software
: abstraction only, the hardware doesn't know.

Well, the hardware doesn't know, but the state of the hardware does
matter.  Maybe that's where my confusion comes from.

: >: 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.

Agreed.  They will still be built, but there won't be a lot of them.
Of course, there never were a lot of them...  I'm wondering how I'm
going to test 16 ports of 1mbps traffic, for example...

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

Agreed.

: >: 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.

I tend to agree.  The serial layer is a spigot.  You get bits in, you
pump bits out and there are some rules about when/how you can do both
or react to changes in the signaled interface.  Driver shouldn't know
anything at all about line disciplines.  They know just enough to call
them now, but it seems like that should be done at a different 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 ?)

Or the mini-layer for sound drivers.  Or the abstraction cam provides
for scsi and atapi controllers, etc.

: 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.

The console thing is a mess, but a very useful mess :-(.

: 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)

Yes.  That matches some ideas I've had on the tty layer for some time
now.

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

OK.  I'll plow forward on the cyclades driver I'm working on then.  I
think having 3 people that have recently written a tty driver would be
useful.  Although Bruce hasn't written one recently (that I know
about), his knowledge is extensive there too...

Warner