assignment to avoid one bug and several pessimizations.
In the old version, gcc-2.6.3 (i386 version) generates 16 bytes
of static data and copies it using 4 4-byte load-stores. gcc-2.7.2
generates 2 1-byte stores and calls memset() to zero 14 bytes.
Linking fails because memset() doesn't exist in the kernel.
In both versions, the 2 bytes stored directly are all that is
actually used unless the null padding at the end is used, since
the 3 4-byte words in the middle are initialized again by struct
assignment. These words are misaligned. gcc generates misaligned
load-stores for (small) misaligned struct copies.
Submitted by: Bruce Evans
an application #defines `noreturn'.
Changed one instance of `const' similarly. This is less like to be a
problem since applications shouldn't #define `const', and the common
hack of #defining `const' as nothing gives harmless (?) null attributes
instead of syntax errors.
Fixed comments on #endifs to match code.
common labels for LINT. There are still some common declarations for the
!KERNEL case in tcp_debug.h and spx_debug.h. trpt depends on the ones in
tcp_debug.h.
common labels for LINT. There are still some common declarations for the
!KERNEL case in tcp_debug.h and spx_debug.h. trpt depends on the ones in
tcp_debug.h.
bug only affected FPU emulators. It might have caused bogus FPU states
in core dumps and in the child pcb after a fork. Emulated FPU states
in core dumps don't work for other reasons, and the child FPU state
is reinitialized by exec, so the problem might not have caused any
noticeable affects.
Cleaned up #includes.
(1) The new NO_CDROM Boolean variable means "don't put the distfile/
package on the CDROM you're going to sell". It will basically
turn off everything if FOR_CDROM is set.
Many of the NO_PACKAGE ports are actually "don't sell for profit"
types, which we shouldn't have any problem distributing via ftp.
(2) The new RESTRICTED Boolean variable means don't build this unless
you know what you are doing. It doesn't have any effect unless
NO_RESTRICTED is also set.
(3) BROKEN means this port is broken. At least it will now show up in
INDEX and README.html, and give people more incentive to fix (I
hope).
RESTRICTED and BROKEN are expected to replace the pseudo-targets
in parent Makefiles. (The RESTRICTED and BROKEN list didn't do
anything before, they were solely for grepping purposes.)
(4) The Motif support brings in four new variables: REQUIRES_MOTIF,
which the porter sets for ports that require Motif to build;
HAVE_MOTIF, which the user sets to indicate the system has Motif;
MOTIF_STATIC, which the user sets to indicate that the static
libXm, instead af the default dynamic library, is to be used; and
MOTIFLIB, which is set to "${X11BASE}/lib/libXm.a" or
"-L${X11BASE}/lib -lXm", depending on whether MOTIF_STATIC is set.
The porter is expected to replace all occurrences of libXm in the
{Im,M}akefiles with ${MOTIFLIB}, and this will allow both dynamic
linkage (for users with Motif) and static linkage (for those who
build packages to be used by those withot Motif, i.e., me ;)
automatically.
Original Motif support idea by: graichen
dbopen() to open an NIS map.
Testing with very large maps (e.g. a sample password database with 31,000+
entries) has shown that ypserv will leak memory (ps shows RSS and VSZ
growing to 4000 pages or more) when performing repeated yp_next()s or
a yp_all(). The problem with yp_all() is not immediately obvious since
the ypproc_all service is handled in a child process which exits once
the transfer is finished, but with repeated yp_next()s (like what you
get when you use getpwent() to scroll through the password database),
the parent ypserv grows to enormous size and never shrinks again.
It seems this is related to the HASHINFO parameters I used in yp_dblookup.c,
which I actually stole from pwd_mkdb. Calling dbopen() with the default
parameters (specifying openinfo as NULL) fixes the problem.
I still need to see how this impacts the other NIS tools. I'm also
considering changing from hash to btree databases: the hash database
method doesn't support R_CURSOR, which means yp_next_record() has to
do a lot of ugly work in order to reach an arbitrary location in the
database.
was duplicated until the canq filled up, and write() normally returned 0.
This case is apparently rare. It was reported for Jove's shell buffer in
PR 1130.
Clarified GUS DMA Settings.
Other misc. changes.
This should hold us over until I can finish cleaning up TASD, and finish
reintegrating all of the FreeBSD changes to the sound driver. At that time
this document will be removed, and it's information moved to the handbook.
accepting connections on the FTP port and forking children processes to
handling them. This is lower overhead than spawning ftpd from inetd and
can be a significant win on busy FTP servers. Be sure to disable ftpd in
inetd.conf if you decide to use this option.
These changes are based on similar changes I made to wu-ftpd and have
been in use on wcarchive for several months.
with valid names, the ***/---names were taken first.
this broke eg:
Index: foo/Makefile
==========
RCS <blah>
Retrieving <blah>
diff <blah>
*** Makefile <blah>
--- Makefile <blah>
By trying to patch the Makefile in the _curent_ directory, rather than
the one in the foo/ directory.
When PPP gets an uncompressed packet, it attempts to save off the TCP/IP
header for use in decompressing subsequant packets. If PPP gets garbage
(such as what happens when there is a port speed mismatch or modem line
noise), it will occasionally mistake the packet as a valid uncompressed
packet. When it tries to save off the header, it doesn't bother to check
for the validity of the header length and will happily clobber not only
the PPP VJC data structure, but parts of other process memory that happens
to follow it...causing, ahem, undesired behavior.
header for use in decompressing subsequant packets. If cslip gets garbage
(such as what happens when there is a port speed mismatch or modem line
noise), it will occasionally mistake the packet as a valid uncompressed
packet. When it tries to save off the header, it doesn't bother to check
for the validity of the header length and will happily clobber not only
the cslip data structure, but parts of other kernel memory that happens
to follow it...causing, ahem, undesired behavior.
