the first place was so that BPF could grok trailer packets. I've since
decided that this is a job for tcpdump to decipher (if at all). Also
fixed up checks for received packet length to better cope with ancient
starlan boards.
1) cut this up into /sys/sys/inflate.h, sys/kern/inflate.c
sys/kern/ingact_gzip.c
2) make a lot more things static
3) make a lot of globals const
4) make some args const
5) first stage of making globals into a struct (not used yet)
The vm_allocate() call which was introduced between revisions 1.4 and
1.5 of imagact_gzip.c broke things. I have backed that out for the time
being. (Davidg: help please)
WARNING: if you have gzip enabled in your kernel, you must now run
config again, as another source file has been added. Otherwise your
kernel compile will fall over.
This is all still WIP. More commits to come.
Suggestions from: phk.
Submitted by: Thomas David Rivers <rivers%ponds@ncren.net>
WARNING: might hide some bug below! I commit this to improve the stability
of 2.0.
Thomas wrote:
-------------
I have been running a kernel with this change since October 4th; barring
unrelated network router troubles, the pitiful little machine has
completed several builds without any interaction from me, and continues
to chug along.
I re-read wd.c, and added appropriate printfs() to look for references
to dk_badsect[]. My changes should have printed something when dk_badsect[]
was referenced.
I got no output :-(
Thus, I'm forced to concluded that something else is examining some
spurious memory... which happened to be in dk_badsect[] of the disk structure
in wd.c. I can find no other explanation of why this unnecessary
initialization causes things to operate correctly.
On the premise that such an initialization isn't going to hurt anything,
I'm going to suggest it go into 2.0.
I'd like to thank everyone for there assistance, particularly David,
John and Bruce.
controlled by a runtime switch.
(b) add '-P' to toggle passive mode from the command line
(c) turn on passive mode by default
- passive mode ftp works on all but a few servers out there
- it's easy to disable
- no, standard ftp should not run with passive enabled by default,
but that doesn't matter because I've already fixed standard mode
ftp to take a switch
This really should have been implemented as a ncftp "set" command instead
of carrying over the same hack that was done to ftp. I will go back and fix
it some day.
on terminals with no pad char (cons25) and quote from tputs.c says so too:
! * Too bad there are no user program accessible programmed delays.
! * Transmitting pad characters slows many
! * terminals down and also loads the system.
more weird kinds of a.out than anyone can argue for. This code failed to
load the first 28K of the text-segment, in the case where the first page
of the a.out contains only the a.out-header, and the text is still at 0x0.
Thanks Steven !
been relocated to run in the 64k segment at 0x10000 with the stack at
the top of this segment. This corrects the problems machines with 512K
base memory had booting.
2. startprog routing rewritten to convert the BOOTSEG ss to a KERNELSEG
ss, this eliminated the last of the >512K memory references. Additional
cleanup in here included a better way to copy the arguments to the
kernel stack.
3. Elimination of argv and esym cruft saved a few bytes.
4. Only need to truncate the head.a_entry to a meg boundary once intead
of every time we used it! [Saving more bytes].
5. Addition of version 1 bootinfo structure support. These boot blocks
pass the kernel name in to the kernel now.
6. Removed historical comments about MACH argv stuff, as it is useless now.
that and when it does it will be done differently.
2. The kernel now does a frame setup on entry so it ``looks'' like a
real function call. This will be needed by future boot code and
debuggers.
3. Clean up stack offsets to all be in decimal and use %ebp when copying
parameters in from the boot code.
4. Implement version 1 of the uniform boot code passing mechanism with
support for kernelname passing and nfs_diskless structure passing.
5. Document the 3 different ways the kernel is called depending on what code
is calling it.
