shared signal handling when there is shared signal handling being
used.
This removes the main objection to making the shared signal handling
a standard ability in rfork() and friends and 'unconditionalising'
this code. (i.e. the allocation of an extra 328 bytes per process).
Signal handling information remains in the U area until such a time as
it's reference count would be incremented to > 1. At that point a new
struct is malloc'd and maintained in KVM so that it can be shared between
the processes (threads) using it.
A function to check the reference count and move the struct back to the U
area when it drops back to 1 is also supplied. Signal information is
therefore now swapable for all processes that are not sharing that
information with other processes. THis should addres the concerns raised
by Garrett and others.
Submitted by: "Richard Seaman, Jr." <dick@tar.com>
to release the probe ccb before taking down the periph.
Also, don't do cdscheduling if you're not going to
attach the device after all.
Reviewed by: ken@freebsd.org
Reads the output of 'diff -r' and splits it into separate
patch files, one per file. The files are named 'patch-XX'
where XX is aa, ab, ac, ... Useful when creating ports.
from sc, vt and sio drivers. Use instead a linker_set to collect them.
Staticize ??cngetc(), ??cnputc(), etc functions in sc and vt drivers.
We must still have siocngetc() and siocnputc() as globals because they
are directly referred to by i386-gdbstub.c :-(
Oked by: bde
Teach it about the FreeBSD equivalent, because there are some funny things
going on with -rpath that I can't quite get a handle on. It looks like
setting an rpath on a new shared object overrides all the implicit
DT_RPATH's from the dependencies, causing them to fail at link time
(but not runtime).
already loaded and interpreted userconfig_script. Otherwise, when using
such kernel system would always block waiting for user input in UserConfig,
while the intention was to avoid this by having userconfig_script.
Reviewed by: msmith
that they might be about to blow their feet off if they have not been
reading their mail. I don't know if or how well this will work, but it's
worth a try.
committers. A 'make aout-to-elf' is strongly encouraged. This isn't quite
the end of the line for people who have a real problem with updating yet,
but we've got to get this over and done with. Yes, it's bound to be a
couple of bumpy couple of days.
It keeps returning queue full until we have reduced the number of tagged
openings to the minimum.
So, put in a quirk entry with the same work-around. This quirk entry is
only for the 9G Atlas III, once someone comes up with inquiry information
for the 18G version of that drive, we can quirk it as well.
Submitted by: "Johan Granlund" <johan@granlund.nu>
downward growing stacks more general.
Add (but don't activate) code to use the new stack facility
when running threads, (specifically the linux threads support).
This allows people to use both linux compiled linuxthreads, and also the
native FreeBSD linux-threads port.
The code is conditional on VM_STACK. Not using this will
produce the old heavily tested system.
Submitted by: Richard Seaman <dick@tar.com>
MNT_WAIT when we mean boolean `true' or check for that value not being
passed. There was no problem in practice because MNT_WAIT had the
magic value of 1.
- document that sysctl() and sysctlbyname() return 0 on success
- if the provided buffer is too small, set errno to ENOMEM and return -1
instead of returning ENOMEM.
and mx_setcfg() so that we can read the internal MII registers on the
MX98713 chip correctly. With these changes, media autoselection now
works correctly on the original 98713. All Macronix chips should now
be properly supported (unless there's a surprise waiting in the 98725).
Thanks to Ulf Zimmermann for providing a 98713 board.
target (see the previous log message). This works for bootstrapping
from 2.2.7. It won't work for bootstrapping from 2.1.x, but that
fails due to include problems earlier.
list of devices which has been changed in UserConfig, without resorting
to reading /dev/kmem.
The data returned consist of series of struct isa_device and
char dev_name[8].
Ok'd by: jkh
