file. The field formerly contained random garbage, leading to spurious
differences between otherwise identical executables and libraries.
Submitted by: Bruce Evans <bde@freebsd.org>
of mbufs in use. If the number reached, e.g., 4 digits, then later
decreased to 3 digits, the last digit of the 4-digit number was
not erased. This caused the display to show a wildly high number of
mbufs in use.
not based on gpl'ed code, just prototype and usage. I'm not 100% certain
they behave the same while the system is in trouble (eg: malloc() failing)
but in those circumstances all bets would be off anyway.
These routines work like sprintf() and vsprintf(), except that instead of
using a fixed buffer, they allocate memory and return it to the user
and it's the user's responsibility to free() it. They have allocate as
much memory as they need (and can get), so the size of strings it can deal
with is limited only by the amount of memory it can malloc() on your
behalf.
There are a few gpl'ed programs starting to use this interface, and it's
becoming more common with the scares about security risks with sprintf().
I dont like the look of the code that the various programs (including
cvs, gdb, libg++, etc) provide if configure can't find it on the system.
It should be possible to modify the stdio core code to provide this
interface more efficiently, I was more worried about having something
that worked and was secure. :-) (I noticed that there was once intended
to be a smprintf() routine when our stdio was written for 4.4BSD, but it
looks pretty stillborn, and it's intended interface is not clear). Since
Linux and gnu libc have this interface, it seemed silly to bring yet
another one onto the scene.
Requested by: joerg
(Note, this is mostly going to be conflicts, which is expected. Our entire
sh source has a mainline, so this should not change anything except for
a few new files appearing. I dont think they are a problem)
a condition when blocking can occur, and the daemon did not check properly
for a page remaining on the expected queue. Additionally, the inactive
target was being set much too large for small memory machines. It is now
being calculated based upon the amount of user memory available on every
pageout daemon run. Another problem was that if memory was very low, the
pageout daemon could fail repeatedly to traverse the inactive queue.
problem. BY MISTAKE, the vm_page_unqueue (or equiv) was removed from the
vm_fault code. Really bad things appear to happen if a page is on a queue
while it is being faulted.
(returns EPERM always, the errno is specified by POSIX).
If you really have a desperate need to link or unlink a directory, you
can use fsdb. :-)
This should stop any chance of ftpd, rdist, "rm -rf", etc from
bugging out and damaging the filesystem structure or loosing races
with malicious users.
Reviewed by: davidg, bde
Kernel Appletalk protocol support
both CAP and netatalk can make use of this..
still needs some owrk but it seemd the right tiime to commit it
so other can experiment.
guru out there can find a way to take advantage of little-endianness to
make this computation more efficient. (I am certain that it can be done,
but haven't managed to make it work myself.)
