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>