MOUNT_LFS to "lfs" in one place. The merge was painful because it
conflicted with cosmetic FreeBSD changes. lfs_cleanerd still compiles
cleanly but has aproximately the same chance of working as before (0).
types. The NetBSD compatibility cruft was more correct for -current
than FreeBSD's own code. It just used NetBSD #defines instead of
string literals for the filesystem names. NetBSD's MOUNT_UFS is
"ffs", so using a literal "ufs" gives wrong results, but this is
unimportant, especially for bootstrapping.
Fixed style bugs in trymmap().
Fixed some disordered declarations.
via wollman's changes in rev.1.2 being adopted by Lite2 and the
nfsv3 changes in rev.1.3 being adopted by both FreeBSD and Lite2.
We were only missing lookup of the type number for nfs (MOUNT_NFS
doesn't exist in Lite2).
isn't a prerequisite, since it isn't required for the prototypes
and isn't always needed to call the functions (the address family
might be a variable).
- Set UN_ULOCK in union_lock() when UN_KLOCK is set. Caller expects
that vnode is locked correctly, and may call another function which
expects locked vnode and may unlock the vnode.
- Do not assume the behavior of inside functions in FreeBSD's
vfs_suber.c is same as 4.4BSD-Lite2. Vnode may be locked in
vget() even though flag is zero. (Locked vnode is, of course,
unlocked before returning from vget.)
Move sigjmp_buf and jmp_buf structure definitions to machine/setjmp.h
so that i386 can continue to use int as the basic register type and
alpha can use long. Bruce was concerned about possible differing
alignment. I've left the definition of _JBLEN in machine/setjmp.h
even though Bruce's example used the number directly. I don't know if
any other code relies on _JBLEN, so I left it to avoid potential
breakage.
so that existing programs which were compiled before the introduction
of the new mouse code and use these ioctls will run unmodified.
Suggested by msmith.
limit sendmail to 500 messages per run
keeps the process from growing too large
sort the queue by host, not numeric priority
connecting to a host is too expensive,
once we got the connection, ram all the mail down his throat ;>
real path here for the mount device (or path). This fixes difficulties
unmounting devices that are actually symlinks to real devices.
Also, print the original path instead of the real path in early error
messages. nfs path handling and later error messages may still be wrong,
probably only in silly cases where the original path is both a symlink
and a remote path.
PR: 5208
Note: this may cause some problems in a few cases. With very old versions
of rpcgen, if you defined a procedure called foo, then rpcen would create
client stubs for function foo_1() and server stubs _also_ with function
foo_1(). This only worked because of the lack of ANSI prototypes: the
client side stub takes different arguments than the server side stub.
(The client side takes a CLIENT * handle, while the server side wants
an svc_req *.)
To fix this conflict, rpcgen in ANSI mode generates foo_1() for the client
and foo_1_svc() for the server. RPC server code that depends on the old
behavior might break because of this. (Fixing it is just a matter of
adding the _svc suffix onto the server procedure names.)
size was rounded up to a multiple of the fragment size, but this
gave invalid file systems when the fragment size was > SBSIZE (fsck
aborts early on them). Now a fragment size of 32768 seems to work
(too-simple tests with fsck and iozone worked).
superblock is invalid, fsck looks at the label to help guess where
the next superblock should be. If the partition type is 4.2BSD,
fsck assumed that the block size was valid and divided by it, so
it dumped core if the size was 0.
Initialization of the label was broken almost 3 years ago in rev.1.9
of newfs/newfs.c. Newfs does not change the label at all, so there
is no problem (except the breakage of the automatic search for
backup superblocks) unless something else sets the partition type
to 4.2BSD. However, it is too easy to set partition types to
4.2.BSD by copying an old label or by using a disktab entry to
create the label.
PR: 2537
0xefbfe000) and kernel_start (normally 0xf0100000).
Things are unnecessarily (?) difficult because procfs is used to
access user addresses in the live-kernel case although we must have
access to /dev/mem to work at all, and whatever works for the
dead-kernel case should work in all cases (modulo volatility of
live kernel variables). We used the wrong range [0, kernel_start)
for user addresses. Procfs should only work up to VM_MAXUSER_ADDRESS,
but it bogusly works for reads up to the address 2 pages higher
(the user area, including the kernel stack, is mapped to where the
user area used to be (WTUAUTB)). Procfs can not work at all for
addresses between WTUAUTB and kernel_start.
Now we use procfs only to access addresses up to VM_MAXUSER_ADDRESS.
Higher addresses are translated normally using kvtophys(), so the
user ptd is used for addresses below the real kernel start (0xf0000000;
see INKERNEL()) and nothing is found WTUAUTB.
Strange accesses that cross the user-kernel boundary are now handled,
but such ranges are currently always errors because they necessarily
overlap the hole WTUAUTB.
Short reads are still not handled.
Correct translations would have been null. However, kstack was
the top of the kernel stack instead of the base of the kernel stack
like it was when the kernel exported it, so the area above the
kernel stack was mistranslated and the kernel stack was not
translated. This bug was depended on to compensate for the wrong
value of kstack - to read the pcb, instead of just using the address
of the pcb, we used the mistranslated address of kstack, which
happened to be the same (curpcb = kstack - 0x2000).
This area is simpler than it used to be now that the kernel stack
address is per-process. The code still seems to be more complicated
than necessary - the `found_pcb == 0' case seems to be unused.
a null pointer panic when the pointer for the incorrect process is
NULL. getpriority() was broken in rev.1.27. Rev.1.28 broke the
warning instead of fixing the problem.
PR: 5495
gdb was cloned from the buggy version of kvm_uread() in libkvm and
had the same bugs. It looped endlessly on EOF and checked errno
without setting it in the lseek() error check. The first bug caused
gdb to loop endlessly for reads from addresses between the end of
the user area and the start of the kernel text. kvm_uread() should
not be used for addresses beyond the end of the user area, but is
due to bugs elsewhere.
the previous frame is in the usual place even for traps, interrupts
and syscalls in the kernel, because the assembly language stubs
don't change the frame pointer. The previous frame is just not for
the calling function. We may as well depend on this as on magic to
determine the trap frame address. The magic is in FRAME_SAVED_PC()
which elides the correct number of stubs (1) to go back to a pc that
matches the previous frame.
Removing fbsd_kern_frame_chain() fixes bugs in it. Xsyscall was
misspelled as _Xsyscall (gdb removes one leading underscore), so
the tf_syscall frame type was never found. This was harmless
because tf_normal works in all cases in fbsd_kern_frame_chain()
and Xsyscall is spelled correctly in fbsd_kern_frame_saved_pc()
where it matters. There were style bugs on almost every line,
starting with a primary indent of 7.
