Yes, there will be conflicts on just about every file. There is a
significant mainline after the initial import, and the "-j" merge conflicts
on the $Id$ lines... Yuck! (These comments apply to the rest of the
imports)
Obtained from: Paul Vixie <paul@vix.com>
Note that this was done by selective patching from diffs, to not conflict
with the 4.4bsd base code.. This was *not* a trivial task.. I have been
testing this code (apart from cosmetic changes) in my libc for a while now.
Obtained from: Paul Vixie <paul@vix.com>
Note: this was done by selective patching from diffs by hand, in order
to not conflict with the 4.4BSD base code. Beta9 was done the same way.
Obtained from: Paul Vixie <paul@vix.com>
Claim the major numbers (before sombedoy else jumps in again and
claims the slots for his foocd driver :-), install all the hooks that
are required.
While i've been at this, i've cleaned up some of the routines at the
end of i386/conf.c; all the importers of the latest CDROM drivers
forgot to fill in the appropriate information. The `ata' driver
(vapourware?) does only occupy a slot in the bdevsw[] array, btw.
The actual import of the code does require a minor change in the SCSI
subsystem, and i want to have this reviewed by Peter first, so it will
be deferred for some days. The driver is already working for me
though.
Submitted by: akiyama@kme.mei.co.jp (Shunsuke Akiyama)
Jordan, you might wish to update sysinstall's builtin knowledge, too.
They are also offering r/o NFS access, will this be interesting for
us? (sysinstall)
that this is a superset of cdplay, and perhaps it's time to send cdplay
into the bit bucket if this works well. According to the docs, it has
a friendlier command structure, command line interface etc.
Submitted by: Serge Vakulenko <vak@cronyx.ru>
change, but I've been testing this on thud and silvia for quite a
while, also I haven't gotten any bug reports from the ports list, so
I'm going to let it loose!
It cleans up this file quite a bit, now I can go in and start adding
some more "interesting" things.... ;)
calls.
Found by: gcc -Wstrict-prototypes after I supplied some of the 5000+
missing prototypes. Now I have 9000+ lines of warnings and errors
about bogus conversions of function pointers.
Note that conf.c, although there was an import conflict, it did not
require intervention, as it was the $Id$ tag. It would have become
rev 1.8 on checkout so there's no point changing it from 1.7 to
1.1.1.3 as the "-j" option wanted to do.. Trust me.. :-)
page. I tried all three modes (rwhod, rwhod -m, rwhod -m 32) on a machine
with 2 ethernet interfaces and they all worked.
Submitted by: Bill Fenner <fenner@parc.xerox.com>
Note, I tested this on a NEC Versa, IBM 750C, and a IBM 755CX w/out
problems. The card still works fine in TP mode.
Submitted by: schwarz@alpharel.com (Steve Schwarz)
Reviewed by: jleppek@suw2k.ess.harris.com (James Leppek)
oo
Turns out, it's pretty important if you use PAX for backup. In the man
page for PAX, there is an error (OK, we could call it a "potentially
catastrophic incompleteness"). It reads:
> The command:
>
> pax -r -v -f filename
>
> gives the verbose table of contents for an archive stored in filename.
Yup, it does do that. With a side effect: it also _replaces_ all the
files that come in from the archive. As is my custom, I did my
backup-validation real soon after the backup was written. Precisely
because I've seen the same sort of thing happen on other systems. So all
that file-restoring didn't do a lot of damage. Probably helped my
fragmentation somewhat (aha, an online defragger?) It did confuse one
hapless user, who lost an email message he _knew_ he hadn't deleted.
Apparently the system restored the file as of just before that critical
message came in.
The correct entry should read:
> The command:
>
> pax -v -f filename
>
> gives the verbose table of contents for an archive stored in filename.
Submitted by: John Beckett <jbeckett@southern.edu> via the BSDI mailing list
Remove some rare-used semigraphics from VT100 entry, it really helps many
not-fully compatible emulators and don't degradate original vt100 much.
Add VT200 keys set to VT100 k1-k4, it not affects original VT100 since no one
program tests keys presense, but helps emulators to work
