| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
the wait.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
new boot code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
from users. Eventually this will be used for LKM support.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
- Allow PPP to run multicasts natively.
- Deal properly with lots of similarly-named interfaces.
- Don't sign-extend if_flags.
NB: the last fix (to rtsock.c) must be reversed when we expand if_flags to a
reasonable size.
Submitted by: Mark Treacy
|
|
|
|
|
|
|
| |
the moment, but will be in the future. Other changes mostly cosmetic,
but are made for future VMIO considerations.
Submitted by: John Dyson
|
|
|
|
|
| |
reduced paging performance by missing a clustering opportunity. Found
by Poul-Henning Kamp with gcc -Wall.
|
|
|
|
|
|
| |
the uncompression buffer. Now malloc(M_GZIP) is used for all the Huffman-
tree stuff only. Numbers so far indicate < 15Kb Malloc use + 32 Kb for
the abovementioned buffer while uncompressing.
|
| |
|
|
|
|
| |
adjkerntz -i, per Bruce suggestion
|
|
|
|
| |
per Bruce suggestion
|
| |
|
|
|
|
| |
pointed by Bruce
|
| |
|
|
|
|
| |
for other weird things in the future (hint, hint!)
|
| |
|
|
|
|
|
|
| |
short. I changed it from 2000 to 4000 and now my disk works fine.
Submitted by: John Hay <jhay@mikom.csir.co.za>
|
|
|
|
|
|
|
| |
drives that return sector counts of 0 and cause division by 0 traps during
the probe).
Reviewed by: Dave <root@hclb.demon.co.uk>
Obtained from: FreeBSD 1.1.5.1
|
|
|
|
| |
buffer deadlock.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
cleaned up much of the cruft in this thing.
No printf's in the case where things go well.
Gzip-headers can contain filenames and comments (as long as they're
shorter than the page-size.)
I don't think we leak memory, in the "exec/aout" code. I'm not quite sure
about the inflate code yet, but I don't think memory is lost.
Q: Can I add a class M_GZIP to <sys/malloc.h> and bump M_LAST one up
without any thing else needing tweaking ?
Poul-Henning
|
|
|
|
|
|
|
| |
inadvertantly introduced in pre-1.1.5. This could cause page modifications
to go unnoticed during certain extreme low memory/high paging rate conditions.
Submitted by: John Dyson and David Greenman
|
|
|
|
| |
but every now and then it will fail without an explanation :-(
|
| |
|
| |
|
|
|
|
| |
made i depend on the src.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
WARNING: THIS MATERIAL MIGHT GO AWAY!
This material needs the core-groups approval to stay here for the 2.0 release.
If the core-group does not concent to this commit, it will be backed out.
***
It is a non-gpl'ed "unzip" which will allow execution of a.out files which
have been sent through "gzip -9". The idea being saved disk-space.
Just now this code has quality rating: "working prototype".
To compress a file to be used with this, do it exactly this way:
gzip -9 -v < /bin/FOO > /tmp/FOO
remember to chmod /tmp/FOO as needed.
DON'T compress all of you binaries right away ! There are several things
which you should consider first:
1. Using compressed binaries, you use >MUCH< more VM, and thus swap-space.
2. It is slow.
3. It might crash your machine.
Apart from that, I welcome comments...
NB: There is also a change to sys/conf/files, but cvs core-dumped on me,
so it didn't get into the logs or emailed, but the commit seems to have
happended OK.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
WARNING: THIS MATERIAL MIGHT GO AWAY!
This material needs the core-groups approval to stay here for the 2.0 release.
If the core-group does not concent to this commit, it will be backed out.
***
It is a non-gpl'ed "unzip" which will allow execution of a.out files which
have been sent through "gzip -9". The idea being saved disk-space.
Just now this code has quality rating: "working prototype".
To compress a file to be used with this, do it exactly this way:
gzip -9 -v < /bin/FOO > /tmp/FOO
remember to chmod /tmp/FOO as needed.
DON'T compress all of you binaries right away ! There are several things
which you should consider first:
1. Using compressed binaries, you use >MUCH< more VM, and thus swap-space.
2. It is slow.
3. It might crash your machine.
Apart from that, I welcome comments...
|
| |
|
|
|
|
| |
Obtained from: scratch :-)
|
|
|
|
| |
picked up from .depend.
|
|
|
|
| |
for instance), don't nuke them.
|
|
|
|
|
|
|
|
|
|
|
|
| |
be merged at some point)
New AMD family ethernet driver. Should support BICC,NE2100, TNIC,
AT1500 and anything else that uses a Lance/PCnet type chip. Only been
tested with the BICC so far though.
Still work to do on performance and MULTICAST support needs to be added
but it's basically working and I want the revision history from this
point on
|
|
|
|
|
|
|
|
|
| |
AT1500 and anything else that uses a Lance/PCnet type chip. Only been
tested with the BICC so far though.
Still work to do on performance and MULTICAST support needs to be added
but it's basically working and I want the revision history from this
point on
|
| |
|
| |
|
|
|
|
| |
Submitted by: HOSOKAWA Tatsumi
|
|
|
|
|
|
| |
Reviewed by:
Submitted by:
Obtained from:
|
| |
|
|
|
|
|
| |
Ripped out the "hooks". Until we know how we want to do it, we shouldn't
start hacking anyway. Still panics my machine though.
|
|
|
|
| |
GCC a lot more silent.
|
|
|
|
|
|
| |
works correctly.
clock.h & reg.h: prototypes.
|
| |
|
|
|
|
| |
bad, I will get to it eventually, unless somebody beats me to it.
|
|
|
|
| |
getting closer all the time.
|
| |
|