Re: spliting kernel ipfw source ? (also involves sctp)

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
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: spliting kernel ipfw source ? (also involves sctp)
    ... it be the case to move them (perhaps with the exception of the userland ... so I tried to make it clear that public headers are excluded: ... 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 ...
    (freebsd-net)
  • Re: C89, size_t, and long
    ... ISO type and the idea behind it is broken; the only valid reason to have ... theoretical possibility of brokenness when you already know that you ... stddef.h in library headers due to bugs in C implementations ... solely on guarantees made by the C standard. ...
    (comp.lang.c)
  • Re: 80386 support in -current
    ... >> don't see any reason why it wouldn't work at all. ... > particular instruction which was introduced with the 486 and must be ... know when it actually works in userland. ... the atomic_cmpset_inttests the usual case of an uncontested lock. ...
    (freebsd-current)
  • Re: C89, size_t, and long
    ... ISO type and the idea behind it is broken; the only valid reason to have ... theoretical possibility of brokenness when you already know that you ... stddef.h in library headers due to bugs in C implementations ...
    (comp.lang.c)
  • Re: Using GDI+ in C++
    ... out how to modify library or API headers. ... that purpose, today, the compiler has a few options that ... The reason for it can be seen by looking at the output of: ... the definitions of the symbols mentioned in the complaints. ...
    (microsoft.public.vc.language)