signal mask since a 1.3 binary may attempt to invoke sigreturn(2) directly
for an alternate exit from the signal handler. If we don't do this, it will
get a garbage signal mask if it tries to do that.
* Increase the size of sigset_t to accomodate 128 signals -- adding new
versions of sys_setprocmask(), sys_sigaction(), sys_sigpending() and
sys_sigsuspend() to handle the changed arguments.
* Abstract the guts of sys_sigaltstack(), sys_setprocmask(), sys_sigaction(),
sys_sigpending() and sys_sigsuspend() into separate functions, and call them
from all the emulations rather than hard-coding everything. (Avoids uses
the stackgap crap for these system calls.)
* Add a new flag (p_checksig) to indicate that a process may have signals
pending and userret() needs to do the full (slow) check.
* Eliminate SAS_ALTSTACK; it's exactly the inverse of SS_DISABLE.
* Correct emulation bugs with restoring SS_ONSTACK.
* Make the signal mask in the sigcontext always use the emulated mask format.
* Store signals internally in sigaction structures, rather than maintaining a
bunch of little sigsets for each SA_* bit.
* Keep track of where we put the signal trampoline, rather than figuring it out
in *_sendsig().
* Issue a warning when a non-emulated sigaction bit is observed.
* Add missing emulated signals, and a native SIGPWR (currently not used).
* Implement the `not reset when caught' semantics for relevant signals.
Note: Only code touched by the i386 port has been modified. Other ports and
emulations need to be updated.
u-area in machine-dependent code. Instead, call exit2() to schedule
the reaper to free them for us, once it is safe to do so (i.e. we are
no longer running on the dead proc's vmspace and stack).
bus_space(9), if drivers want it (they shouldn't; easy to convert) they
can define it right before including bus.h. There's been a release since
the interfaces were (slightly) changed, and no code in the source tree
uses the old interfaces as far as I can tell.
* Improve the midisyn layer a little.
* Add a driver for the Yamaha OPL[23] FM synths.
The opl driver is not finished yet; it sounds pretty awful.
For some strange reason I cannot get any FM sound from my SB64 cards,
but a regular SB16 works fine.
2 reasons:
-no need to keep a list of all known parts
-there is at least 1 bridge (ACC micro 2051) which reports the same
device ID for its various subfunctions; this would require an additional
check in the match function
(keep the old list inside #if 0 in case one of the historical bridges
doesn't report the right class/subclass - I can't check them all)
the /dev/rmidiN devices, or with a sequencer interface via /dev/music.
So far the only supported MIDI device is the MPU401 port on SoundBlaster
(and only on SB on isapnp, since we do not have locators with multiple
values yet).
clock past the End of Time.
If time_t is 32 bits, then the "End of Time" is Jan 18/19 2038
(depending on time zone).
This code copes with RTC's past the end of time if time_t is an int32
or less. It just forces the time back to 2037. This will let users
with screwed up clocks to at least boot and function long enough to
set their clocks to something sane.
This kludge is conditioned on an
if (sizeof(time_t) <= sizeof(int32_t))
which will automatically optimize the code out once we switch time_t
to a 64 bit quantity, which should happen well before 2037.
Patch based on code from Michael C. Richardson, with help from
Allen Briggs who pointed out a fencepost error.
tty structures, and on some machines (namely the DraCo internal lpt, and some
multi-i/o boards for Amigas and DraCos), tying spltty to the pretty high printer
interupt level would hurt serial performance.
On all affected ports but Amiga, spllpt() has been defined in machine/intr.h
to be spltty(), thus preserving old behaviour. Portmasters are encouraged to
change is, if they feel something else is better (e.g., one of its own were
possible).
an effort to avoid bouncing file system buffers (it's not clear how much
of a win this is, and it'll be pointless w/ a unified buffer cache, but
what the heck).
wpaul 1998/07/02 08:36:36 PDT
Modified files:
sys/i386/boot/biosboot start.S
Log:
Add workaround to allow the FreeBSD boot block to work on
Kapok Computer Co. notebook with AMI 'WinBIOS' which seems to insist
on having a short jump and nop as the first instructions in the
boot sector code. The prevailing theory is that the BIOS is doing
some sort of boot sector virus detection and refusing to run any
boot block that doesn't start with the same instruction sequence as
MS-DOG boot sector code. If this is the case, it would be nice if it
actually printed an error message to this effect instead of just
saying 'FAILED.'
This workaround has no effect on the boot sector code other than to
increase its size by three bytes.
address on 2 architectures anyhow. Also, move the definition of the `label_t'
type inside _KERNEL protection, since it is specific to the in-kernel
setjmp()/longjmp() implementations.
as with user-land programs, include files are installed by each directory
in the tree that has includes to install. (This allows more flexibility
as to what gets installed, makes 'partial installs' easier, and gives us
more options as to which machines' includes get installed at any given
time.) The old SYS_INCLUDES={symlinks,copies} behaviours are _both_
still supported, though at least one bug in the 'symlinks' case is
fixed by this change. Include files can't be build before installation,
so directories that have includes as targets (e.g. dev/pci) have to move
those targets into a different Makefile.
a struct device * corresponding to the ISA bus device. The ISA DMA
controller driver functions have been renamed and now take a struct
isa_dma_state *, and are called indirectly by machine-dependent code
which provides the DMA state.
These changes allow e.g. `ofisa' (the OpenFirmware configuration
mechanism for the ISA bus, used by e.g. Sharks) to use the MI ISA
DMA controller code.
is defined, the bus_space macros will check to ensure that the bus address
and the target buffer (if applicable) are aligned properly for the size
of the type being used. If they are not, a message will be displayed on
the console.
While strict alignment is not strictly necessary on the x86, ensuring
proper alignment can aid performance, and help make drivers more portable
to architectures (like the Alpha and StrongARM) which _do_ require strict
alignment.
thorpej