Subject: Mea culpa -- small fix for netboot fixes
In accordance with the unavoidable principle sof Murphy's Law, I discovered
that the fixes I recently contributed for the netboot code had some small
flaws in them. Two of them were just typos and had no effect on how the
program functioned. The other one was a missing line from the rootopts and
swapopts functions I created in bootmenu.c, which was supposed to initialize
the NFS sotype flag. It defaults to UDP, and you can change it to TCP with
the rootopts or swapopts commands, but then you can't change it back again.
I originally had a line at the top of each function to reinitialize this
flag, but somehow it got lost in the shuffle, probably because I don't
actually have a need for that flag yet.
Submitted by: wpaul
menu items aren't unique enough. After half an hour of head-scratching,
here are the disgusting convolutions required to work around the problem.
Sigh..
Sigh. It's hard to test something that screws up a running system when
it works, so I have to do most of this through the rather laborious process
of making boot floppies! ;-(
Change the reference for the libtermcap libtermlib link from SHLIBDIR
to LIBDIR. SHLIBDIR is undefined in the standard case.
termcap.c:
Initialize a local variable to zero. Otherwise an erroneous free call
can happen and clobber the calling program.
Seen with vi and gdb. If you have TERMCAP set with a terminal entry and
set TERM with something like huhu, vi and gdb core dumps.
That was the good news. The bad news is that bad144 is a proper mess,
and I don't have time to fix it now, so you will probably not be able to
use it anyway.
Sorry guys, go out and buy a 100Mb IDE drive and a paddleboard :-(
If somebody wants to pick up on this: bad144 needs to learn how to
stay inside our slice of the disk. That's the trick.
Go to a single dependancy in files.i386. Using a .c file for the
sequencer code won't work since I need to know the size of the program,
so we just include the generated .h file as:
"../../sys/gnu/misc/aic7770/aic7770_seq.h"
Reviewed by:
Submitted by:
Obtained from:
instead. The entire scheme just doesn't work as envisioned (hint: think
about make depend as well as all). Those extremely rare individuals who
actually hack on the sequencer code will know how to keep stuff in sync,
I *do* get the feeling!
Somehow, I don't think this stuff was tested at all! :-(
I really hope that it actually works, though my hopes are steadily diminishing.
Anyone with 27xx/28xx boards in -current is *strongly encouraged* to give this
stuff a shot! Otherwise, I suspect that we'll be punting this out of
2.0. I haven't found a single part of Justin's commit that wasn't broken
in some way.
