from /etc/rc, including inetd and it's children, stuff from
/usr/local/etc/rc.d (eg: squid, apache). The default limits are causing
a lot of problems including things like fsck failing on large disks.
I hope I've understood the quirks of the override mechanism properly.
buffer queue so I missed this when I changed buf_queue_head.
This probably fixes Soren's problem too, but he never mentioned
which CD driver he was using. 8-)
Submitted by: dave adkins <adkin003@tc.umn.edu>
negotiation. Instead, incrementally pause after
receiving LCPs with the same magic. We can now
suffer a server that waits more than 1 second before
responding. Pauses greater than a second get
hopelessly confusing as when the server eventually
starts, it sees a flood of Config Requests followed
by config NAKs and changes of magic. This causes the
server to change its magic over and over.....
file get created. We don't create lock files over non-tty
connections, but we *do* create lock files in -direct mode.
This leaves us capable of adding utmp/wtmp support for
successful pap & chap logins (coming soon).
config request. This stops us from squirting stuff
down a line that still has ECHO turned on because the
peer hasn't had a chance to start yet.
Lead to the cause by: Greg Lehey <grog@lemis.com>
Change the definition of a buffer queue so that bufqdisksort can
properly deal with bordered writes.
Add inline functions for accessing buffer queues. This should be
considered an opaque data structure by clients.
callout.h:
New callout implementation.
device.h:
Add support for CAM interrupts.
disk.h:
disklabel.h:
tqdisksort->bufqdisksort
kernel.h:
Add new configuration entries for configuration hooks and calling
cpu_rootconf and cpu_dumpconf.
param.h:
Add a priority for sleeping waiting on config hooks.
proc.h:
Update for new callout implementation.
queue.h:
Add TAILQ_HEAD_INITIALIZER from NetBSD.
systm.h:
Add prototypes for cpu_root/dumpconf, splcam, splsoftcam, etc..
Add support for "interrupt driven configuration hooks".
A component of the kernel can register a hook, most likely
during auto-configuration, and receive a callback once
interrupt services are available. This callback will occur before
the root and dump devices are configured, so the configuration
task can affect the selection of those two devices or complete
any tasks that need to be performed prior to launching init.
System boot is posponed so long as a hook is registered. The
hook owner is responsible for removing the hook once their task
is complete or the system boot can continue.
kern_acct.c kern_clock.c kern_exit.c kern_synch.c kern_time.c:
Change the interface and implementation for the kernel callout
service. The new implemntaion is based on the work of
Adam M. Costello and George Varghese, published in a technical
report entitled "Redesigning the BSD Callout and Timer Facilities".
The interface used in FreeBSD is a little different than the one
outlined in the paper. The new function prototypes are:
struct callout_handle timeout(void (*func)(void *),
void *arg, int ticks);
void untimeout(void (*func)(void *), void *arg,
struct callout_handle handle);
If a client wishes to remove a timeout, it must store the
callout_handle returned by timeout and pass it to untimeout.
The new implementation gives 0(1) insert and removal of callouts
making this interface scale well even for applications that
keep 100s of callouts outstanding.
See the updated timeout.9 man page for more details.
Add cpu_rootconf and cpu_dumpconf so that configuring these
two devices can be better controlled by the MI configuration
code.
machdep.c:
MD initialization code for the new callout interface.
trap.c:
Add support for printing out whether cam interrupts are masked
during a panic.
close(1);
close(2);
x = open(ctermid(NULL), O_RDWR|O_NONBLOCK);
close(0)
on a tty causes select() to return an exception for descriptor x !
This is the case in RELENG_2_2, but not in 2.2.2. I'm not sure why.
Instead of doing the x=open() and close(0), we just do x=0 now.
Problem pointed out by: Greg Lehey <grog@lemis.com>
Tomi Vainio <tomppa@fidata.fi>
