From owner-freebsd-hardware Wed Nov 27 14:44:26 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA18643 for hardware-outgoing; Wed, 27 Nov 1996 14:44:26 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA18635 for ; Wed, 27 Nov 1996 14:44:21 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id JAA32072; Thu, 28 Nov 1996 09:36:12 +1100 Date: Thu, 28 Nov 1996 09:36:12 +1100 From: Bruce Evans Message-Id: <199611272236.JAA32072@godzilla.zeta.org.au> To: gerg@stallion.oz.au, hardware@FreeBSD.ORG Subject: Re: FreeBSD as Terminal Server Cc: alex@yahoo.com, bde@zeta.org.au, sos@ravenock.cybercity.dk, sysseh@devetir.qld.gov.au Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>You'd need to translate the istallion driver from the Linlish :-). > >Huh?? >What do you mean? >How mush more FreeBSDish can it be made? plainBSDish: use spltty() to disable tty interrupts. Never use disable_interrupt(), which doesn't exist exist in plainBSD. FreeBSDish: use only spltty() as in plainBSD, unless the driver uses a fast interrupt handler. Fast interrupt handlers are harder to program, so they should only be used if an interrupt latency of less than about 10 ms is required. E.g., for a serial driver at 115200 bps, a fast interrupt handler should be used if the receiver fifo size is smaller than about 128. There are several sources of huge interrupt latency in FreeBSD. E.g., tty interrupts are masked for 2-5 ms while the keyboard LEDs are being programmed. `bio' (disk) interrupts may preempt non-fast tty interrupt handlers and run for as long as 20 ms to transfer 64K of data to a slow MFM/IDE disk. >>The current version is too green to use. It disables interrupts >>and calls tsleep() :-(. > >I would hardly call it green, people have been using them very happily >for more than a year now... I think it works because tsleep() normally calls cpu_switch() and cpu_switch() happens to enable interrupts. >>I did a quick check for drivers in isa/*.c that abuse disable_intr() >>and found these: >> >>ctx.c: disables interrupts and calls uiomove(). Apart from disabling >[driver list sniped] > >Did you let of the maintainers of these drivers know so they could >"fix" up the problem? These drivers are mostly apparently unmaintained :=]. >In any case this is very easy to "fix" for the Stallion drivers. If you >look at a lot of the cases of the disabled interrupts they are turned off >for no more than a couple of dozen instructions... Yes, that is safe. To be sure that they are not turned off for longer, don't call any function outside the driver, since the implementation of foreign functions is unknown and may change. Foreign functions may execute thousands of instructions or reenable interrupts. Bruce