Date: Mon, 29 May 1995 06:39:03 +0800 (WST) From: Peter Wemm <peter@haywire.DIALix.COM> To: hackers@FreeBSD.org Subject: aargh! How to handle 128 ttys on a system? Message-ID: <Pine.SV4.3.91.950529052026.28077D-100000@haywire.DIALix.COM>
next in thread | raw e-mail | index | archive | help
I have a Specialix SI and XIO driver running on a FreeBSD-current box here. There's only one problem.. It supports up to 128 ports per host - how the !@#^&% does one use meaningful names for them all without colliding with some other driver? Also, the probe/attach only leaves the card in a quiescent state. I'm using a user mode program the uploads the firmware for the host controller and booting it in /etc/rc*. This step also configures the port array. Was there a decision made on the best place to put these during the boot sequence? I still have an unresolved problem though.. I'm getting an obscure panic after a line is hung while being flow control blocked.. Something like: "putc to a clist with no reserved cblocks" or something like that. My first browse over the code doesn't pick up anything obvious yet. It appears to be happening after DCD goes up after getty has done a blocking open in carrier wait. I'm wondering if it's some peculiar variation between the different clist implementations of different OS's. One more thing.. I really dont want to statically allocate 256 tty structures (attached printer support..) at compile, when in fact there may be as little as 4 ports present at boot. I had a look at the other drivers, and there seems to be some sort of taboo on dynamically allocating the tty structure.. Things like: #if __FreeBSD__ >= 2 /* cant dynamically allocate ttys yet */ #else /* bsdi || FreeBSD 1.x || netbsd */ ... code to allocate the tty structures .... #endif and so on. What gives? OBTW: How many minor numbers can I have? I snooped in /dev and found some unit numbers up in the high millions... This would be really nice if I dont have to try and resort to multiple major's. Currently, there is a maximum of 128 ports. It currenty uses a single minor per port, which is configured to optionally hotwire DCD for terminals. There are no cua ports. and there is a control minor. To fit that in, the driver currently only allows 31 of the ports on the 4'th host card to be used. There's no room to spare if there's 256 minors supported. (the minor() macro in <sys/types.h> is certainly.. umm.. "interesting.." ). it might make sense to use the lower 8 bits as a port number, and bits 16 upwards as a "type".. 0 = modem, 1 = terminal (DCD ignored), 2 = transparent print, 3 = (maybe) cua and so on. Does that sound reasonable? IMHO: CUA ports are a crude hack which suck pretty badly. I really dont want to propagate it if possible. We use our own getty which does uucp style locking, and initialises the modem, and manually answers it when it sends a RING. Rather similar to mgetty I guess, but it solved all our modem problems.. This doesn't work with the cua scheme very well at all. Transparent print is far more useful to us than cua ports.. Tip can (IMHO) go jump. We use taylor-uucp dialing routines in our pppd, so that's not an issue for us. I'm currently using the "test" major number, 20. For those that dont know, Specialix systems are a host controller card, which provides a control bus, buffering, cooking, etc, and the remote panels are either custom logic (the old SI series), or a pair of CD1440's in the XIO panels. Each panel has 8 ports, and each host card supports 4 panels in a bus arrangement, and the drivers generally support 4 host cards per system, either in interupt driven mode, or by polling every 10 milliseconds. (there's a decent buffer size..). [ Incidently, It has no similarity to the the other CD1440 cards, because the hardware interface does not expose you to the actual panels. The host firmware does all that. ] They run at 115K on all ports. So.. Who can I bug for assistance in figuring out why the code can panic on FreeBSD clists and not on BSDI 2.0 clists? (I'm assuming that something needs some subtle, non-obvious change because of the way ttys/clists are implemented here... BTW: I'm a native speaker of STREAMS.. this clist stuff is pretty alien to me...) And next on my list of drivers to port, is the Stallion high-speed sync serial card driver that we use. (In case you haven't guessed, I'm out to make an Annex/Netblazer alternative.. ;-) -Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.91.950529052026.28077D-100000>