Instead of being a no-op, kn03_intr_enable() sets the sw copy of the
interrupt-enable mask *and* writes it into the IO asic intr-enable
register. Boot code sets the sw copy (kn03_tc_imask) to something
sane (KN03_IM0, with tc option slots turned off). Tested and works.
Interrupt code for other IOASIC machines should be redone so that
interrupts for devices are enabled by drivers, rather than by
cpu-specific boot code. Functions common to all IOASIC machines
(PSWARN?) should be done by asic_init().
Checked in without the above changes so that 3MAX+, MAXINE and 3MIN
interrupt-(enable,handle) can converge.
latter would lead to undefined symbols if DDB not defined.
(2) check for break on console, and therefore debugger entry (if ddb
in kernel) earlier, so that the device doesn't need to be open.
(3) return immediately after breaking into the debugger in comeint().
(4) only do the normal character input routine in comintr if receive
mask yeilds _EXACLTY_ LSR_RXRDY. if there's only a receive
error, or there's a receive error _and_ a received character,
do comeint().
(former two by me. latter two from Bob Baron <rvb@cs.cmu.edu>.)
reported this enhancement to fdlibm-comments, and got the following
reply:
Date: Thu, 11 May 1995 14:35:25 -0700
From: Kwok.Ng@Eng.Sun.COM (KC Ng)
To: fdlibm-comments@sunpro.Eng.Sun.COM, jtc@cygnus.com
Subject: Re: fdlibm 5.2: why do core functions use sqrt?
> I noticed that core (e_*.c) fdlibm functions like __ieee754_acos()
> ensure that they call sqrt() with arguments in range (x > 0), when
> they could call __ieee754_sqrt() directly.
>
> Since sqrt() does a lot more work (verifies x is in range, etc.) is
> there any reason for this? I'd think that calling __iee754_sqrt()
> would be more appropriate. ....
You are right. __ieee754_sqrt should be in use with e_*.c.
INSTALL -- somewhat generic kernel with a snowball's chance of
fitting on an install floppy.
This kernel MUST consist (for users' sanity) of a subset of
the GENERIC configuration. It also should support X reasonably
(though the SysV SHM extensions won't work).
To avoid a maintenance nightmare, this kernel consists of GENERIC
with missing options/devices/etc. REMOVED rather than commented
out. That makes it easy to diff agains GENERIC, to make sure that
it really is a subset of the functionality.
allow Q_SYNC regardless of "target" uid, we allow it with -1;
fix bug that caused all ops to refer to user quotas, not group.
[finally had a chance to check this!]
sysv_shm.c: make shm_find_segment_by_shmid global so it can be used by
COMPAT_HPUX. There should be a better way...
rest: Add #ifdef COMPAT_HPUX where needed
chopps