Date: Sun, 22 Dec 2002 09:59:37 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Darren Reed <darrenr@reed.wattle.id.au> Cc: Sergey Mokryshev <mokr@mokr.net>, Vallo Kallaste <kalts@estpak.ee>, Sam Leffler <sam@errno.com>, Hiten Pandya <hiten@unixdaemons.com>, current@FreeBSD.ORG Subject: Re: PFIL_HOOKS should be made default in 5.0 Message-ID: <3E05FD89.33D7D3E2@mindspring.com> References: <200212220419.PAA21619@avalon.reed.wattle.id.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Darren Reed wrote: > > If you make them non-optional, which is what started this thread, > > then you *are* talking about having to add an option in to get > > rid of them. > > Seriously, Terry, how many "NO_foo" options exist, today ? Any non-zero number of them is too many. Personally, I also dislike the "foo" options, too... anything that requires me to recompile something to use it annoys me. 8-). > > I understand that people all want their pet software to run out > > of the box without modification. > > I'm not the one who wants that, it's people who USE FreeBSD. You > remember users, don't you Terry ? :) Yeah... those are the people we've been writing the new installer for, for the last 6 years, but never finishing it, right? Seriously, the problem is that not enough work has been done to allow segmentation of the fastpath, with accessor/mutator functions, with zero or low cost. The closest you can really get to doing the right thing in the current FreeBSD codebase is to use existing hooks for things that are already there, and eat the overhead you were going to eat anyway. That works out to "no new overhead, abuse existing overhead, work to eliminate existing overhead in future releases". A good example of terrible overhead that should not be there is that the IPv4 code bloats the per connection data horribly, when IPSEC is enabled, but not being used. Another good example is in the ip_input code calling a function that does a pcb hash lookup for divert/fast bridging, and then calls it again in tcp_input, rather than passing the lookup, that was already completed, in as part of the context for the tcp_input. Ideally, there would be a combined has space that ipfilter, the bridging code, DSR, TCP splicing, the SYN cache, and everybody else who wanted to do connection state based decisions would use. The only reason I even commented was that it seems to me that there was an attempt at an end-run to get more overhead in for some excuse other than the real one. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E05FD89.33D7D3E2>