Kris Kennaway wrote:
On Thu, Jun 14, 2007 at 10:25:15PM -0400, Randall Stewart wrote:
Kris Kennaway wrote:
On Thu, Jun 14, 2007 at 10:59:04PM +0000, Randall Stewart wrote:
rrs 2007-06-14 22:59:04 UTC
FreeBSD src repository
Modified files:
sys/netinet sctp.h sctp_asconf.c sctp_asconf.h
sctp_bsd_addr.c sctp_constants.h
sctp_indata.c sctp_input.c
sctp_lock_bsd.h sctp_os_bsd.h
sctp_output.c sctp_pcb.c sctp_pcb.h
sctp_peeloff.c sctp_sysctl.c
sctp_sysctl.h sctp_timer.c sctp_uio.h
sctp_usrreq.c sctputil.c sctputil.h
sys/netinet6 sctp6_usrreq.c
sys/conf options
Log:
- Fix so ifn's are properly deleted when the ref count goes to 0.
- Fix so VRF's will clean themselves up when no references are around.
- Allow sctp_ifa to be passed into inpcb_bind, addr_mgmt_ep_sa to bypass
normal validation checks.
- turn auto-asconf off for subset bound sockets
- Moves all logging to use KTR. This gets rid of most
of the logging #ifdef's with a few exceptions reducing
the number of config options for SCTP.
| +#ifndef SCTP_SUBSYS_KTR
| +#define SCTP_SUBSYS_KTR KTR_GEN
| +#endif
Brief silence after previous disapproval doesn't equal approval ;-)
What was wrong with the method I suggested, namely using KTR_SUBSYS if
a SCTP_TRACE option is included in the kernel? That is the intended
way that events local to a particular subsystem should be handled.
Kris
I asked if KTR_GEN was ok.. I can use KTR_SUBSYS.. sure.. but that
means I can't really run witness on my machine as I test.. since
witness is the only one that uses KTR_SUBSYS.. No one else uses
KTR_GEN.. why is it a problem using one.
WITNESS does not use itq:
#if 0
#define KTR_WITNESS KTR_SUBSYS
#else
#define KTR_WITNESS 0
#endif
KTR_WITNESS is used for debugging of the WITNESS code itself (probably
no-one has needed to use it for many years). It is a completely
orthogonal purpose to yours, so they can co-exist happily.
KTR_GEN is for "general events". SCTP is not a general event, it's
localized events belonging to a particular subsystem.
So whats wrong with using a unused one?
If you look at the history there was a big effort to reclaim these
fields. Because space is at such a premium here there needs to be a
strong reason for using up a spare field. SCTP does not strike me as
such a reason, particularly since the alternative seems quite
practical.
Kris
Ok.. whatever you say.. I can change it very easily ;-)
R
--
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
