packet flow into two unidirectional flows.
Part of a suite of nodes developed for packet flow control.
More to follow as I have time to port them to 5.x or
as others do so. The ipfw node will be the hardest..
Submitted by: "Vitaly V. Belekhov" <vitaly@riss-telecom.ru>
- Remove unneeded spl()'s around mi_switch() in userret().
- Don't hold sched_lock across addupc_task().
- Remove the MD function child_return() now that the MI function
fork_return() is used instead.
- Use TRAPF_USERMODE() instead of dinking with the trapframe directly to
check for ast's in kernel mode.
- Check astpending(curproc) and resched_wanted() in ast() and return if
neither is true.
- Use astoff() rather than setting the non-existent per-cpu variable
astpending to 0 to clear an ast.
- Don't hold sched_lock around addupc_task() as this apparently breaks
profiling badly due to sched_lock being held across copyin().
Reported by: bde (2)
for us.
- Change the switch_trampoline() to call fork_exit() passing in the
required arguments instead of calling the fork trampoline callout
function directly.
Warning: this hasn't been tested.
Looked over by: dfr
Submitted by: Maxim Konovalov <maxim@macomnet.ru>
Silence a warning by renaming the 'pgtok' #define to 'vmstat_pgtok' so
as not to conflict with the 'pgtok' #define in sys/param.h
* Rip out MACHINE_CPU stuff from sys.mk and include a new <bsd.cpu.mk>
after we pull in /etc/make.conf. We need to do it afterwards so we can
react to the user setting of the:
* CPUTYPE variable, which contains the CPU type which the user wants to
optimize for. For example, if you want your binaries to only run on an
i686-class machine (or higher), set this to i686. If you want to support
running binaries on a variety of CPU generations, set this to the lowest
common denominator. Supported values are listed in make.conf.
* bsd.cpu.mk does the expansion of CPUTYPE into MACHINE_CPU using the
(hopefully) correct unordered list of CPU types which should be used on
that CPU. For example, an AMD k6 CPU wants any of the following:
k6 k5 i586 i486 i386
This is still an unordered list so the client makefile logic is simple -
client makefiles need to test for the various elements of the set in
decreasing order of priority using ${MACHINE_CPU:M<foo>}, as before.
The various MACHINE_CPU lists are believed to be correct, but should be
checked.
* If NO_CPU_CFLAGS is not defined, add relevant gcc compiler optimization
settings by default (e.g. -karch=k6 for CPUTYPE=k6, etc). Release
builders and developers of third-party software need to make sure not to
enable CPU-specific optimization when generating code intended to be
portable. We probably need to move to an /etc/world.conf to allow the
optimization stuff to be applied separately to world/kernel and external
compilations, but it's not any worse a problem than it was before.
* Add coverage for the ia64/itanium MACHINE_ARCH/CPUTYPE.
* Add CPUTYPE support for all of the CPU types supported by FreeBSD and gcc
(only i386, alpha and ia64 first, since those are the minimally-working
ports. Other architecture porters, please feel free to add the relevant
gunk for your platform).
Reviewed by: jhb, obrien
* Rip out MACHINE_CPU stuff from sys.mk and include a new <bsd.cpu.mk>
after we pull in /etc/make.conf. We need to do it afterwards so we can
react to the user setting of the:
* CPUTYPE variable, which contains the CPU type which the user wants to
optimize for. For example, if you want your binaries to only run on an
i686-class machine (or higher), set this to i686. If you want to support
running binaries on a variety of CPU generations, set this to the lowest
common denominator. Supported values are listed in make.conf.
* bsd.cpu.mk does the expansion of CPUTYPE into MACHINE_CPU using the
(hopefully) correct unordered list of CPU types which should be used on
that CPU. For example, an AMD k6 CPU wants any of the following:
k6 k5 i586 i486 i386
This is still an unordered list so the client makefile logic is simple -
client makefiles need to test for the various elements of the set in
decreasing order of priority using ${MACHINE_CPU:M<foo>}, as before.
The various MACHINE_CPU lists are believed to be correct, but should be
checked.
* If NO_CPU_CFLAGS is not defined, add relevant gcc compiler optimization
settings by default (e.g. -karch=k6 for CPUTYPE=k6, etc). Release
builders and developers of third-party software need to make sure not to
enable CPU-specific optimization when generating code intended to be
portable. We probably need to move to an /etc/world.conf to allow the
optimization stuff to be applied separately to world/kernel and external
compilations, but it's not any worse a problem than it was before.
* Add coverage for the ia64/itanium MACHINE_ARCH/CPUTYPE.
* Add CPUTYPE support for all of the CPU types supported by FreeBSD and gcc
(only i386, alpha and ia64 first, since those are the minimally-working
ports. Other architecture porters, please feel free to add the relevant
gunk for your platform).
Reviewed by: jhb, obrien
+ Add support for the new SENDMAIL_MC make.conf knob
+ Add the ability to build .cf files from .mc files
+ Generalize map rebuilding
+ Add the ability to rebuild the aliases file
+ Add the ability to stop, start, and restart sendmail
PR: bin/13759, bin/19897, bin/24397
users should be configuring via m4 now. If set, use m4 to create the .cf
file. Also, if either SENDMAIL_MC or SENDMAIL_CF is set, 'make install' or
'make distribution' in src/etc/sendmail/ will install the appropriate .cf as
/etc/mail/sendmail.cf. This fixes some mergemaster problems.
PR: conf/13016
and one for Makefile options, pass in the list head and use a common
newopt() routine.
Fix the 'config vmunix' support glue which was broken for a few minutes.
Makefile to the etc/sendmail Makefile to be consistent with all of the
other /var file creations. In doing so, change the Makefile target from
etc-sendmail.cf to distribution as it installs more than just the sendmail.cf.
an interrupt thread while the interrupt thread is blocked on Giant waiting
to execute the interrupt handler being removed. The result was that the
intrhand structure would be free'd, and we would call 0xdeadc0de. The work
around is to check to see if the interrupt thread is idle when removing a
handler. If not, then we mark the interrupt handler as being dead using
the new IH_DEAD flag and don't remove it from the interrupt threads' list
of handlers. When the interrupt thread resumes, it will see a dead handler
while traversing the list of handlers and will remove the handler then.
