This fixes the kernel panic when propagating userconfig changes to
arbitrary kernels.
Remove obsoleted `#include <tcl.h>' added a few <stdio.h> where
necessary.
Fix getting scsi bus information from an -incore kernel.
Turned on SAVE_USERCONFIG by default.
required. a core is not dumped at first connecting time and
dumped at second or third time. (patch I)
2. A routine for "show route" refers out of allocated space.
Values pointed by "lp" should be read as CHAR, I think.
there is also no free() for disallocation. (patch II)
Here is also a patch for an improvement: In current imprementation,
even if PPP connection is disconnected by time out, prompt of
interactive mode does not change from "PPP>" to "ppp>" to
indicate the disconnection on a terminal.
So I modified the code to do that. (patch III)
Submitted-By: NAKAMURA Motonori <motonori@econ.kyoto-u.ac.jp>
on their own without even attempting to get concensus in the IETF, but
there are also lots of Win95/NT boxes out there.
CLoses PR#1494
Submitted-By: Peter Childs <pjchilds@imforei.apana.org.au>
For me, more often than not, the backgrounded syslogd daemon is not
yet ready to process log messages before other things (such as named)
want to log a heap of them. It seems that it's the O_SYNC writes of
the stuff coming in from /dev/klog that's the slowdown.
Anyway, instead of using the libc daemon, roll a modified version. This
one has a timeout. The child will wait for either the timeout to expire
or the child process to signal it to let it know that it's "ready" and
the /dev/log socket is set up and active, so it's safe to continue the
boot. It adds a small fraction of a second pause to the boot time, but on
the other hand the overall boot time is *quicker* since the disk is not
being thrashed while the log messages are getting written out synchronously
one by one while other daemons are loading in parallel.
The timeout is in case the child segfaults or something before becoming
fully operational.
SLIP/PPP devices, putting them before the others in the network device
selection menu.
2. Change "Other" to "URL" so as not to conflict with the keyboard accellerator
for the "OK" button in FTP site selection menu.
3. Detect the NULL last symbol in the name list and initialize the other
members correctly.
First, change sysinstall and the Makefile rules to not build the kernel
nlist directly into sysinstall now. Instead, spit it out as an ascii
file in /stand and parse it from sysinstall later. This solves the chicken-n-
egg problem of building sysinstall into the fsimage before BOOTMFS is built
and can have its symbols extracted. Now we generate the symbol file in
release.8.
Second, add Poul-Henning's USERCONFIG_BOOT changes. These have two
effects:
1. Userconfig is always entered, rather than only after a -c
(don't scream yet, it's not as bad as it sounds).
2. Userconfig reads a message string which can optionally be
written just past the boot blocks. This string "preloads"
the userconfig input buffer and is parsed as user input.
If the first command is not "USERCONFIG", userconfig will
treat this as an implied "quit" (which is why you don't need
to scream - you never even know you went through userconfig
and back out again if you don't specifically ask for it),
otherwise it will read and execute the following commands
until a "quit" is seen or the end is reached, in which case
the normal userconfig command prompt will then be presented.
How to create your own startup sequences, using any boot.flp image
from the next snap forward (not yet, but soon):
% dd of=/dev/rfd0 seek=1 bs=512 count=1 conv=sync <<WAKKA_WAKKA_DOO
USERCONFIG
irq ed0 10
iomem ed0 0xcc000
disable ed1
quit
WAKKA_WAKKA_DOO
Third, add an intro screen to UserConfig so that users aren't just thrown
into this strange screen if userconfig is auto-launched. The default
boot.flp startup sequence is now, in fact, this:
USERCONFIG
intro
visual
(Since visual never returns, we don't need a following "quit").
Submitted-By: phk & jkh
kernel" mechanism. This is just the foundation - more work follows
and will be committed over the next few hours.
Submitted-by: "Eric L. Hernes" <erich@lodgenet.com> & jkh
possibility of security holes allowing root penetration.
Inspired by: Mark Handley <M.Handley@cs.ucl.ac.uk> and
Theo de Raadt <deraadt@theos.com> independently
Submitted by: Theo de Raadt <deraadt@theos.com>
