spliting kernel ipfw source ? (also involves sctp)

[Luigi Rizzo]

On Mon, Mar 02, 2009 at 06:30:27PM +0000, Robert Watson wrote:
..
> >>Luigi Rizzo wrote:
> >>>Hi, I am planning to split netinet/ip_fw2.c in a number of smaller files 
> >>>to make it more manageable, and while i do this I would also like to 
> >>>move the files related to ipfw2 (namely ip_fw*c) to a better place. Any 
> >>>objection to moving them to sys/netinet/ipfw2 ? Also, I can't help 
> >>>noticing that sys/netinet/ contains 36 files related to sctp -- wouldn't 
> >>>it be the case to move them (perhaps with the exception of the userland 
> >>>headers) to a separate subdirectory ?
...
> I think massively rearranging things doesn't by us much in terms of beauty, 
> but does give us a lot in terms of hassle, given current assumptions of 
> alignment between the layout of /usr/include and the layout of 
> /usr/src/sys. We'd need to introduce new explicit mappings to install 
> include files in their old locations (which are required by applications), 
> etc.  For a change with such a minor benefit, the hassle will be huge.  I'm 
> fine with renaming the ipfw .c files and leaving in netinet, but let's not 
> get carried away.

I suspect that the mention of symlinks (which is not mine and absolutely
not what I want to do) triggered some alarms :)

I have very clear the potential nightmare with careless moving
of files, so I tried to make it clear that public headers are excluded:
as you see i wrote "ip_fw*c" and "exception of the userland headers".

To further clarify, my plan is the following:

- leave ip_fw.h and ip_dummynet.h in /sys/netinet in case
  userland code is dependent on their location;
- create /sys/netinet/ipfw/ to hold the kernel .c files related to
  ipfw and possibly dummynet (and also their private headers if any);

I am not going to touch other people's stuff, though I repeat that
sctp would clearly deserve a cleanup -- i doubt userland needs more
than one or possibly two headers (one for the basic stuff, one for
the fancy and possibly non-portable stuff). Tcp has similar issues
especially for recent additions.

More than the number of files in /sys/netinet/, i am worried by the
amount of private headers that are exposed to userland for no good
reason. In fact, some of them are contain:

	#ifndef _KERNEL
	#error "no user-serviceable parts inside"
	#endif

Part of this is for historical reasons, but we should try to move
to a better structure.
Take e.g. tcp_var.h contains the stats (that some userland program
may want to have) but also a ton of internal structures (e.g. those
for SACK support) that have appeared very recently and have no reason
to be there.

	cheers
	luigi