GSoC 2013

[John Marino]

On 4/5/2013 12:54, InterNetX - Robert Garrett wrote:
> The bsd licensed stuff is, something that is actually a fairly large 
> task. It includes bringing now very old code up to the standards of the 
> gnu tools. However it is by far the least useful of what was mentioned.
> 
> The work on pf, though not necessarily FreeBSD's work, would be though. 
> I am not certain we should follow FreeBSD's lead, with there approach to 
> PF. I actually would like to see work done to bring in the updated code 
> from Open, or perhaps NPF.. Either of these are complex enough if done 
> properly to qualify as GSOC proposals.

On 4/5/2013 14:04, Jerome Portal wrote:
> Indeed, it's not in the GSoC project list, I saw it at 
> http://www.dragonflybsd.org/docs/developer/ProjectsPage/#index6h3 ; but 
> as it is in the projects page, I wanted to ask if it could be a task 
> aiming at porting a big bundle of tools.


So I see there are different interpretations already.
Regarding Robert's, he's saying it's not porting tools but developing them.  At that's not DragonFly-specific.
Regarding Jerome's: My suggestion (and it's just my opinion) is not to look at tools where DragonFly has a good alternative already.  Porting tools that DragonFly doesn't have, such as DTrace, or significantly improving the GDB/KGDB in base to work better (pass gdb testsuite, handle dragonfly threads, etc) is something much more compelling.

Back to Robert, on topic of flavors of PF:
We had a long discussion about this on IRC.
The OpenBSD PF is a massive beast to chase.  lentferj spent weeks changing tens of thousands of lines, and we were still left with an old version (he said you had to upgrade to each one, not just jump).  Apparently this is a never-ending chase so basing it on OpenBSD PF seems logical until you realize how much work it really is.
NPF probably suffers from the same thing to a lesser extent, except that's it's NetBSD-specific.  We have a general interest in what's going on with it, but to my knowledge no DragonFly developer has been involved or even invited.  And there's the point that it's not even production ready.
FreeBSD PF (Which needs a new name) makes a lot of sense because:
1) the remaining similarities between FreeBSD and DragonFly
2) It's focus on SMP
3) It's relatively static -- port it once, it's probably much easier to maintain than the other two

Nobody is saying this -or- this -or- this.  We could theoretically have all 3, but freebsd PF has the best chance of success in the longterm IMO.  I don't think anyone here is terrible interested in packet filter development, just this final product, so the easier it is the better.