source files via a 'cc -include opt_global.h ...' type arrangement.
This means we can untangle certain header files.
options.i386 has a placeholder until it has a real member so we can avoid
having to teach config about it just yet.
Reviewed by: bde
This commit includes the following changes:
1) Old-style (pr_usrreq()) protocols are no longer supported, the compatibility
glue for them is deleted, and the kernel will panic on boot if any are compiled
in.
2) Certain protocol entry points are modified to take a process structure,
so they they can easily tell whether or not it is possible to sleep, and
also to access credentials.
3) SS_PRIV is no more, and with it goes the SO_PRIVSTATE setsockopt()
call. Protocols should use the process pointer they are now passed.
4) The PF_LOCAL and PF_ROUTE families have been updated to use the new
style, as has the `raw' skeleton family.
5) PF_LOCAL sockets now obey the process's umask when creating a socket
in the filesystem.
As a result, LINT is now broken. I'm hoping that some enterprising hacker
with a bit more time will either make the broken bits work (should be
easy for netipx) or dike them out.
1) i586_bcopy() problem
There have been a number of reports that the syscons doesn't work
properly if i586_bcopy() is enabled.
The problem prevented users from installing 2.2(.1)-RELEASE. The
symptom is that the system looks frozen during device probe or just
before the main installation menu. The workaround was to specify the
flag 0x01 to the npx device so that i586_bcopy() is disabled.
The patch forces the syscons to call generic_bcopy() when copying
to/from the video memory, even if CPU is Pentium and i586_bcopy() is
enabled. i586_bcopy() is still called for copy operations between
non-video memory regions.
PR: kern/2277, kern/3066, kern/3107, kern/3134
2) video mode parameter table problem
The syscons reads and uses the video mode parameter table provided by
the VGA BIOS to set VGA registers when changing video mode and
modifying font data. It appears that in some VGA BIOSes the table is
not ordered as the syscons expects, and this leads to screen
corruption.
The problem prevented users from installing 2.2(.1)-RELEASE. The
symptom is the corrupt screen or strange vertical lines soon after the
kernel is loaded into memory (just after the kernel decompression).
The patch performs simplistic test and if it fails, set video_mode_ptr
to NULL so that the video mode switching won't happen.
This is an interim kludge. There should be a better way to deal with
the problem.
PR: kern/2498, conf/2775, conf/3354
Reviewed by: sos
Tested by: PR originators (not all of them, though)
The SMP source was merged into 3.0-current last nite and this broke
the make of sbin/dset.
Should make things work for non-SMP case.
People making SMP kernels will need to edit i386/isa/isa_device.h, re-enabling
'#include "opt_smp.h"'. People making SMP worlds will have to punt for now...
I'm thinking about the real solution, but for now the goal is to NOT break
the world!
modules from src/bin/ls, and handling exec(_PATH_LS,..) as a
special case, very useful in an environment where many users
are given chroot access. "~/etc/{s}pwd.db" files are still
needed if uid/gid->user/group translation is desired.
To enable this it must be compiled with the make variable
FTP_INTERNAL_LS defined, either in /etc/make.conf or the
environment.
There are various options documented in i386/conf/LINT, there is more to
come over the next few days.
The kernel should run pretty much "as before" without the options to
activate SMP mode.
There are a handful of known "loose ends" that need to be fixed, but
have been put off since the SMP kernel is in a moderately good condition
at the moment.
This commit is the result of the tinkering and testing over the last 14
months by many people. A special thanks to Steve Passe for implementing
the APIC code!
When we request sense, don't allow disconnection. This closes a window
where we might allow an overlapped tagged and non-tagged transaction.
The correct fix is to freeze the queue for the target that requests sense
which is what will happen in the new CAM framework.
Our vput calls vm_object_deallocate() --> vm_object_terminate(). The
vm_object_terminate() calls vn_lock(), since UN_LOCKED has been
already cleared in union_unlock(). Then, union_lock locks upper vnode
when UN_ULOCK is not set. The upper vnode is not unlocked when
UN_KLOCK is set in union_unlock(), thus, union_lock tries to lock
locked vnode and we get panic.
(ignored :-() errors for `make depend' in /sys/i386/boot/*. It's
natural for there to be no libraries there and inconvenient to check
for this in bsd.prog.mk.
