Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 7 Jan 2010 22:43:34 +0100
From:      Luigi Rizzo <rizzo@iet.unipi.it>
To:        Michael Tuexen <tuexen@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: moving sctp to a separate directory ? (Re: svn commit: r201523 - head/sys/netinet)
Message-ID:  <20100107214334.GA35184@onelab2.iet.unipi.it>
In-Reply-To: <20100107203536.GB8230@rincewind.paeps.cx>
References:  <201001041825.o04IPcXb043347@svn.freebsd.org> <20100104190024.GA47532@onelab2.iet.unipi.it> <517EF225-7EEB-4844-A0AD-019AD72F9403@freebsd.org> <20100104222323.GA49068@onelab2.iet.unipi.it> <20100107203536.GB8230@rincewind.paeps.cx>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 07, 2010 at 09:35:36PM +0100, Philip Paeps wrote:
> On 2010-01-04 23:23:23 (+0100), Luigi Rizzo <rizzo@iet.unipi.it> wrote:
> > This was the reason why I moved ipfw-related stuff out of the way
> > and plan to do the same with tcp unless someone precedes me.
> 
> Please discuss this on -net or so first.  I have worked in an environment

here we are :)

> where tcp was moved out of netinet when it was imported (around 2.2.8-time)
> and it opens the door to a number of strange phenomena.

I think i know pretty well the problems involved, because I have
done the process already for ipfw/ (so you can see how i proceeded)
and this is not just related to the number of files but also to
their size.
I know that adding a few lines to a header, or a few functions to
a file, is often quicker for the programmer than partitioning the
files.  But when files and directories become 3..10 times larger
than their original version at least calls for a scrutiny of whether
the content still fits the original design.

> What do you do with udp, for instance?  Compared to tcp and sctp, it's
> trivial in terms of code, but it's an upper layer protocol from the
> perspective of netinet/netinet6 - do we put it in its own directory too?
> Also note that this won't only cause churn for people who have patches against
> or (out-of-tree) branches from netinet/, but also in other kernel subsystems
> which rely on tcp -- nfs, for instance.

+ I have no intention to move headers whose name constitutes a de-facto
  standard for userland apps; that would be stupid, as it would break
  a lot of stuff over which we have no control.
+ there is also no reason to move single files (such as udp)
  somewhere else.
+ i don't much follow the issue churn on nfs or kernel subsystems: .c files
  are not #included, and headers will be handled with due care, see above.
  Plus, we usually try to make the kernel buildable after such changes.
+ i find the concern about churn in external patchsets a bit weak, first of
  all because this is bound to happen unless we stop all development,
  and secondly because this kind of file moving or splitting happens
  once every 10-15 years which is well beyond the lifetime of a patchset.

cheers
luigi



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100107214334.GA35184>