> I don't think a rewrite is ever going to be much of a good idea, > a restructuring might, meaning that fixing up all the layering > and making it more flat like Van Jacobson suggested (and Linux > implemented in one of their stack of the year projects) might > gain us performance.
I would disagree, and I'll say why in a second. > A rewrite is only necessary when you can't solve a particular > semantic or performance problem without a major kludge. Right > now we don't have any of those problems and a rewrite would > mearly throw away years apon years of testing along with making > our implementation incompatible with the texts out there which > would raise the bar for anyone attempting to base their code on > ours. Please tell me how to solve the following problems with the current stack: 1) Adding a new bit of processing in the input side of IP WITHOUT modifying ip_input. The solution should be generic. 2) Running the stack in a true multi-threaded and multi-instance environment but still within the kernel. (This is a project currently under way in several places, all commercial.) 3) Run the same stack in the kernel and in user space so that it can more easily be debugged. I submit that all of these require a rewrite and if done the resulting stack could compete quite well in the non-core router market and actually create new markets by bringing the barrier to creating incremental changes to the system down. > I agree that a rewrite without a clearly stated goal is almost always > just a euphamism for "i didn't like the variable names and indenting > of the old system" or "i want my name on the top of each file in > the sys/netinet directory". Agreed. > Lastly, I wish we just drop it until we come up with a solid reason, > all this is doing is second guessing stuff that has worked for > years. This code has existed in mostly working order for half of > my lifetime I really don't feel much anyone has the skills necessary > to duplicate the equivelant of several hundered man years of > developement in just a couple of months no matter how highly they > think of themselves. > There may not be a SINGLE solid reason, but it must be an issue otherwise it would never have come up. I think it's a good idea, if done carefully. The original TCP/IP stack and the changes since then were created in a different software era. I'm not saying to build the whole thing again in Java but I am saying that there comes a time when you have to stop putting on band aids and actually have the bone reset. Later, George To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
