In message <[EMAIL PROTECTED]>, David Greenman writes:
>> I'm getting the unfortunate impression that evolution is being
>> frowned upon here. Are their other people that frown the proposal out
>> there to this extent? (i.e. "don't change it if it works") I'd like to
>> hear some important voices on this issue so that I can decide whether to
>> just drop this entire thing and forget about it. (in other words, what do
>> committers and/or core have to say about this?)
>>
>> Aside from this, I've gotten several other "pro" opinions on this;
>> some people have even sent suggestions. So I know that I am not the only
>> one (not by far, in fact) to see an opportunity to benefit from this.
>> Either way, I know *I* will be using this code in time to come, so I
>> suppose the question is:
>> Would you consider committing this code or should I stop posting any
>> changes I make in the future altogether?
>
> What I'm doing is challenging your assertions that spending CPU cycles to
>save memory in the networking code is the right thing to do. I'm further
>saying that I have direct experiance in this area since I'm one of the primary
>people in FreeBSD's history that have spent major amounts of effort in
>improving its performance, especially in the networking area.
David, not all FreeBSD systems come with 128MB ram or more. We have
a significant market of very small systems where a different policy
might make a lot more sense.
I agree that real numbers will have to be used to make any decisions
however.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
