Page MenuHomeFreeBSD

protosw: separate pr_input and pr_ctlinput out of protosw

Authored by glebius on Aug 12 2022, 8:13 AM.
Referenced Files
Unknown Object (File)
Thu, May 23, 5:28 AM
Unknown Object (File)
Sat, May 11, 10:08 PM
Unknown Object (File)
Fri, May 10, 7:00 PM
Unknown Object (File)
Fri, May 10, 10:40 AM
Unknown Object (File)
Tue, May 7, 6:54 AM
Unknown Object (File)
Mon, May 6, 12:08 PM
Unknown Object (File)
Wed, May 1, 9:21 PM
Unknown Object (File)
Tue, Apr 30, 10:34 PM



The protosw KPI historically has implemented two quite orthogonal
things: protocols that implement a certain kind of socket, and
protocols that are IPv4/IPv6 protocol. These two things do not
make one-to-one correspondence. The pr_input and pr_ctlinput methods
were utilized only in IP protocols. This strange duality required
IP protocols that doesn't have a socket to declare protosw, e.g.
carp(4). On the other hand developers of socket protocols thought
that they need to define pr_input/pr_ctlinput always, which lead to
strange dead code, e.g. div_input().

With change pr_input and pr_ctlinput as part of protosw disappear
and IPv4/IPv6 get their private single level protocol switch table
ip_protox[] and ip6_protox[] respectively, pointing at array of
ipproto_input_t functions. The pr_ctlinput that was used for
control input coming from the network (ICMP, ICMPv6) is now represented
by ip_ctlprotox[] and ip6_ctlprotox[].

ipproto_register() becomes the only official way to register in the
table. Those protocols that were always static and unlikely anybody
is interested in making them loadable, are now registered by ip_init(),
ip6_init(). An IP protocol that considers itself unloadable shall
register itself with its own private SYSINIT().

Diff Detail

rS FreeBSD src repository - subversion
Lint Passed
No Test Coverage
Build Status
Buildable 46982
Build 43871: arc lint + arc unit

Event Timeline

tuexen added a subscriber: tuexen.

OK for SCTP.

Could you please update the testing section with the output of netinet[6] tests?


Q: why can't it be embedded in the functions itself, so we don't use these macros?


Shouldn't it be like the following, so we're sure that the condition always works as expected?


Q: is input == NULL a valid case?


Is it needed for this diff? E.g. I'm not opposed to the change by itself, just trying to limit the scope.
If not needed, maybe worth committing separately?


No more empty line requirement in style(9) :-)


Probably worth asserting that IPPROTO_MAX is >= 256, just in case.


Any chance the static version can still be moved to sctp code? Or, at least, maybe in can be called as scp_init() or similar to avoid having sctp headers here?

This revision was not accepted when it landed; it landed in state Needs Review.Aug 17 2022, 6:53 PM
This revision was automatically updated to reflect the committed changes.