Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 28 Nov 1996 09:36:12 +1100
From:      Bruce Evans <bde@zeta.org.au>
To:        gerg@stallion.oz.au, hardware@FreeBSD.ORG
Cc:        alex@yahoo.com, bde@zeta.org.au, sos@ravenock.cybercity.dk, sysseh@devetir.qld.gov.au
Subject:   Re: FreeBSD as Terminal Server
Message-ID:  <199611272236.JAA32072@godzilla.zeta.org.au>

next in thread | raw e-mail | index | archive | help
>>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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611272236.JAA32072>