Re: Removal of netns - politically correct version
On Wed, 5 Mar 2003, Terry Lambert wrote: if it can be made to work. I would argue that ISA support is more or less just as obsolete, as is 486 support, as is the F00F bug workaround, as is ... a lot of code that's still there. Three of my machines have the F00F bug; my firewall, my print server and my laptop - I happened to test this earlier today, while upgrading my last 4.5-pX machines. I also use ISA network cards a bit, and a lot of on-motherboard things seem to be logically ISA devices. I don't have any 486s now, but that is more to do with end-of-life ones not being prefitted with a useful amount of memory. I'd be very grateful if ISA support and the f00f workaround stayed in FreeBSD for a long time yet. Regards, William Palfreman. -- W. Palfreman. I'm looking for a job: Tel: 0771 355 0354 http://www.palfreman.com/william/ for my CV. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Hi, Here's a hint: The Apollo Domain and XNS networking protocols will no longer be offered after Cisco IOS Release 12.2. Information about these protocols will not appear in future releases of the Cisco IOS software documentation set. http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a008007fba7.html He's dead, Jim. -- Bob Bishop +44 (0)118 977 4017 [EMAIL PROTECTED] fax +44 (0)118 989 4254 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Bob Bishop wrote: Here's a hint: The Apollo Domain and XNS networking protocols will no longer be offered after Cisco IOS Release 12.2. Information about these protocols will not appear in future releases of the Cisco IOS software documentation set. http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a008007fba7.html He's dead, Jim. The code is still useful as a simple implementation, much more easily understood by the student than the current TCP/IP stack, for certain. Given that the current TCP/IP stack no longer matches the Stevens books, and given that Stevens is too dead to update the books to the new FreeBSD stack, even if he wanted to, it's useful to have a relatively simple set of code that can be understood without a book that's not getting written. Also, it's interesting from the perspective of people with living Xerox Alto hardware (not many, but they do exist), but I fully admit that that's not a compelling reason. On the other hand, there's no compelling reason to dike it out, if it can be made to work. I would argue that ISA support is more or less just as obsolete, as is 486 support, as is the F00F bug workaround, as is ... a lot of code that's still there. In any case, Peter pointed out that my patch was against -stable, not -current. I'm in the process of CVSup'ing new sources now, and will update the patch against -current, and post it, most likely tomorrow morning, if the CVSup doesn't complete in the next hour. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
* De: Terry Lambert [EMAIL PROTECTED] [ Data: 2003-03-05 ] [ Subjecte: Re: Removal of netns - politically correct version ] On the other hand, there's no compelling reason to dike it out, if it can be made to work. I would argue that ISA support is more or less just as obsolete, as is 486 support, as is the F00F bug workaround, as is ... a lot of code that's still there. I have a 486, lots of people have 486 PC 104 boards. I have a lot of ISA stuff. VLSI support would be equally obsolete. So would support for a Sequent SMP 386. We don't support them. We have at least one feature you demonstate over and over needs moved to the attic. -- juli mallett. email: [EMAIL PROTECTED]; aim: bsdflata; efnet: juli; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Terry Lambert [EMAIL PROTECTED] wrote: Given that the current TCP/IP stack no longer matches the Stevens books, and given that Stevens is too dead to update the books to the new FreeBSD stack, even if he wanted to, it's useful to have a relatively simple set of code that can be understood without a book that's not getting written. Actually the Stevens books are still useful as a guide to the FreeBSD IP stack because they give the important overview and description of how the parts fit together. The details might be different but not enough to confuse a competent programmer. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ ROCKALL MALIN HEBRIDES: CYCLONIC BECOMING WEST OR SOUTHWEST 6 TO GALE 8, OCCASIONALLY SEVERE GALE 9 IN MALIN AND HEBRIDES AT FIRST. SQUALLY SHOWERS. GOOD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Terry Lambert (Wed, Mar 05, 2003 at 04:15:11AM -0800) wrote: Tony Finch wrote: The details might be different but not enough to confuse a competent programmer. Same argument, in favor of the netns code. It's a moot point anyway, I just fixed netns. Sorry to but in, but I don't see why this so called bikesheed keeps getting bigger and bigger. The outcome is simple. If your patches function properly, then there is no need to remove netns provided you don't mind maintaining it. If it doesn't have a maintainer, then just apply your fixes and shuv it in the Attic so it's less horid when someone wants to restart the effort of maintaining it. Not that I can do anything about it, but I can't see why this discussion is getting bigger and bigger for no reason. Cheers. PS. Just my 2 cents. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
if it can be made to work. I would argue that ISA support is more or less just as obsolete, as is 486 support, as is the F00F bug workaround, as is ... a lot of code that's still there. That's just being silly. ISA support is still very much a requirement. Laptops usually have ISA stuff in them. Even modern systems do. My Shuttle box developed all sorts of issues when I removed ISA support from the kernel. They were all solved when I put it back in. We're talking about legacy stuff IN USE. If no one noticed it was broken for years then no one used it. It all seems like there was zero interest in in until it was announced that it was going away and suddenly someone wants to keep it around and submit patches, etc. It wasn't a case of I'm still using it, here's a patch to make it work. It was I did some work last night to patch it so it would compile. Those are 2 VERY different arguments. I would say that you should submit your patches and documentation by all means should anyone in the future. But if no one needs it, the code should be retired. Lack of a maintainer, lack of a userbase, issues with kernel maintenance are all valid reasons to retire code. This is code that the manufacturer wanted kept years ago and then didn't bother to keep up their end of the bargain. Fix it if you want, but it should probably be axed. My probably uninformed .02$. -Chris Corayer To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Hiten Pandya wrote: Sorry to but in, but I don't see why this so called bikesheed keeps getting bigger and bigger. The outcome is simple. If your patches function properly, then there is no need to remove netns provided you don't mind maintaining it. If it doesn't have a maintainer, then just apply your fixes and shuv it in the Attic so it's less horid when someone wants to restart the effort of maintaining it. I am willing to take and respond to all bug reports about the code. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Terry Lambert writes: Mark Murray wrote: Only if it kills this _really_ dumb debate. In time, it will no longer compile, and then the situation will be the same as just punting to the Attic without the fix. Only if some idiot breaks the API contract again. Whatever happened to you broke it, you fix it? Hopefully, the next time it happens, and something gets punted to the Attic, it will be code *you* care about, instead of code I care about. Then it will be *your* problem, and I can sit back and make smarmy postings. Guess what? This has already happened. I'm working on a fix. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Terry Lambert writes: Let' start wth the libalias/natd incremental checksum update code; the code is based on RFC1141, instead of RFC1624. As a result, it get updated incorrectly occasionally, because it's using two's complement instead of one's complement math. Per RFC1642: RFC 1141 yields an updated header checksum of -0 when it should be +0. This is because it assumed that one's complement has a distributive property, which does not hold when the result is 0 (see derivation of [Eqn. 2]). People see this as hands on FTP installs, etc., going through FreeBSD based NAT's. It's very obvious ad easy to repeat: 1)Put a printf in tcp_input.c that compalins when the checksum is incorect. 2)Do a CVSup from that machine through a FreeBSD NAT How long can this remain unfixed before the code is diked out, and the checksum is recalculated fully, instead? Terry, you sound rather foolish when you argue like this. This is semantic tomfoolery and off topic. End of thread. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Hi At 08:53 5/3/03, Terry Lambert wrote: [...] The code is still useful as a simple implementation, much more easily understood by the student than the current TCP/IP stack, for certain. The same is true for netipx (wc -l *.[ch] is almost identical). -- Bob Bishop +44 (0)118 977 4017 [EMAIL PROTECTED] fax +44 (0)118 989 4254 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
On Wed, 5 Mar 2003, Terry Lambert wrote: The code is still useful as a simple implementation, much more easily understood by the student than the current TCP/IP stack, for certain. And it will still be available. It'll just be available in the Attic. The fact that it will get more broken in the future because it's not being maintained in the tree is not terribly significant since it's already broken now. On the other hand, there's no compelling reason to dike it out, There is at least one, namely that it will make kernel code updates easier to do, and easier to test. if it can be made to work. I would argue that ISA support is more or less just as obsolete, as is 486 support, as is the F00F bug workaround, as is ... a lot of code that's still there. Your argument here is non sequitur because we still have large bases of users and developers that have and use this hardware. I retired a box with an original P90 f00f bug cpu not that long ago, for example. netns has neither freebsd users or developers, and hasn't for years. In any case, Peter pointed out that my patch was against -stable, not -current. I'm in the process of CVSup'ing new sources now, and will update the patch against -current, and post it, most likely tomorrow morning, if the CVSup doesn't complete in the next hour. I think that fixing the current brokeness is still useful, even if it gets axed. Putting it to bed with a full tummy will make future educational value of the code that much higher. Doug -- This .signature sanitized for your protection To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Juli Mallett wrote: * De: Terry Lambert [EMAIL PROTECTED] [ Data: 2003-03-05 ] [ Subjecte: Re: Removal of netns - politically correct version ] On the other hand, there's no compelling reason to dike it out, if it can be made to work. I would argue that ISA support is more or less just as obsolete, as is 486 support, as is the F00F bug workaround, as is ... a lot of code that's still there. I have a 486, lots of people have 486 PC 104 boards. I have a lot of ISA stuff. VLSI support would be equally obsolete. So would support for a Sequent SMP 386. We don't support them. We have at least one feature you demonstate over and over needs moved to the attic. I personally have two 4-port terminal servers that speak XNS. I'm pretty sure that others exist. The argument about IPX is just as simple is true. But it's not useful for educational purposes, because it collides with a protocol in common use; hacking it up isn't a good thing. The argument about Cisco's IOS not supporting it soon is irrelevent, until all the Cisco's on the net have their IOS image updated to the version that doesn't support it. It took about 3 years for the updates to get out there so IPv6 was usable, so we have at least 3 years. If you want to make this argument about orphan code, then make it about orphan code. If you want to make this argument about reduced FreeBSD size, then make it about reduced FreeBSD size. If you want to make it about failure to attract a maintainer, then do that. I can give you reasoned arguments why all of these are wrong, using historical examples from previous major code changes in the FreeBSD source tree. And here we see the source of my previous cynicism: The truth is that you are proving that this was never about the code does not even compile, and you are proving that this was never about no one is willing to maintain the code. If you go ahead and dike the code out, in the future, don't be disingenuous about your motives in doing so, and pretend that they are based on legitimate maintenance concerns, when they aren't. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Doug Barton wrote: On Wed, 5 Mar 2003, Terry Lambert wrote: The code is still useful as a simple implementation, much more easily understood by the student than the current TCP/IP stack, for certain. And it will still be available. It'll just be available in the Attic. The fact that it will get more broken in the future because it's not being maintained in the tree is not terribly significant since it's already broken now. Why don't we let me sumbit patches, apply the things, and *then* dike the code out, if that's your reasoning? On the other hand, there's no compelling reason to dike it out, There is at least one, namely that it will make kernel code updates easier to do, and easier to test. And here people were telling me I was wrong for cynically assuming that the reason people diked out so much code in the past year was because they wanted to perform kernel code updates, without having to maintain all the code they would be touching with those updates... if it can be made to work. I would argue that ISA support is more or less just as obsolete, as is 486 support, as is the F00F bug workaround, as is ... a lot of code that's still there. Your argument here is non sequitur because we still have large bases of users and developers that have and use this hardware. I retired a box with an original P90 f00f bug cpu not that long ago, for example. netns has neither freebsd users or developers, and hasn't for years. And I have two XNS terminalservers, and there are people on this list with Apollo equipment. Your point was again? In any case, Peter pointed out that my patch was against -stable, not -current. I'm in the process of CVSup'ing new sources now, and will update the patch against -current, and post it, most likely tomorrow morning, if the CVSup doesn't complete in the next hour. I think that fixing the current brokeness is still useful, even if it gets axed. Putting it to bed with a full tummy will make future educational value of the code that much higher. I suggested that before. People are telling me they won't apply the patches before they murder the code. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
On Wed, 5 Mar 2003, Terry Lambert wrote: If you want to make it about failure to attract a maintainer, then do that. Actually several people have made this argument, along with the corollary failure to attract a userbase. -- This .signature sanitized for your protection To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
It took about 3 years for the updates to get out there so IPv6 was usable i have yet to see a cisco ios image supporting ipv6 that was usable in production environment. and i have tried hard. but i will admit to not having seen apollo networking for over a decade. but i probably have not been looking very widely. seems to me that one useful question is whether the netns code being there non-trivially complicates maintenance and/or reliability of other code, and can i compile or module it out if the bits it occupies really bothers me? randy To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Doug Barton wrote: On Wed, 5 Mar 2003, Terry Lambert wrote: If you want to make it about failure to attract a maintainer, then do that. Actually several people have made this argument, along with the corollary failure to attract a userbase. I would claim that non-working code *repelled* the userbase, just as all the packet radio people went to Linux when the ISODE code was murdered and X.25 went away, the same way we are talking about doing to the XNS code now. If your system can't do something, then *of course* you are n'tgoing to attract user who want to do that something: they will go to systems that aren't incapable of doing what they want. I would claim that the failure to attract a maintainer was a result of too stringent control of commit priviledges. There is code lying fallow in FreeBSD now which has no maintainer, for lack of commit priviledges for people willing to maintain the code (and no, I am not making a case for myself here). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
On Wed, 5 Mar 2003, Terry Lambert wrote: Doug Barton wrote: On Wed, 5 Mar 2003, Terry Lambert wrote: The code is still useful as a simple implementation, much more easily understood by the student than the current TCP/IP stack, for certain. And it will still be available. It'll just be available in the Attic. The fact that it will get more broken in the future because it's not being maintained in the tree is not terribly significant since it's already broken now. Why don't we let me sumbit patches, apply the things, and *then* dike the code out, if that's your reasoning? We should. If no one else wants to do it, I'll be glad to. I can raise my kernel commit percentage a whole order of magnitude! (up to 0.0001%) On the other hand, there's no compelling reason to dike it out, There is at least one, namely that it will make kernel code updates easier to do, and easier to test. And here people were telling me I was wrong for cynically assuming that the reason people diked out so much code in the past year was because they wanted to perform kernel code updates, without having to maintain all the code they would be touching with those updates... I think that's definitely part of the motivation, I just think you're wrong to be cynical about it. :) There is no reason not to cut broken, unused code when it will always be available in CVS if someone comes along to make it useful again. if it can be made to work. I would argue that ISA support is more or less just as obsolete, as is 486 support, as is the F00F bug workaround, as is ... a lot of code that's still there. Your argument here is non sequitur because we still have large bases of users and developers that have and use this hardware. I retired a box with an original P90 f00f bug cpu not that long ago, for example. netns has neither freebsd users or developers, and hasn't for years. And I have two XNS terminalservers, and there are people on this list with Apollo equipment. Your point was again? My point is that we do not, and can not have any user base for the code as it exists, and we could not have for years because it doesn't work. The fact that there may be N users of netns in the universe doesn't affect the brokeness of our code as it has existed in recent history. Doug -- This .signature sanitized for your protection To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Terry Lambert writes: Peter Wemm wrote: Terry Lambert wrote: Is there a compelling reason for removing this working code to the Attic? Terry: will you please check your facts? It takes around 30 seconds to find out that it doesn't even compile. [ ... lots of trivial to fix warnings and errors ... ] Tell you what, I'll fix these and post a patch. Will that make you guys happy? This crap is *s* trivial to fix, it's easier to fix than to watch you guys bitch about it not being fixable. Will it be runnable (as in tested), rather than a compile-only fix? M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
* De: Mark Murray [EMAIL PROTECTED] [ Data: 2003-03-05 ] [ Subjecte: Re: Removal of netns - politically correct version ] Terry Lambert writes: Peter Wemm wrote: Terry Lambert wrote: Is there a compelling reason for removing this working code to the Attic? Terry: will you please check your facts? It takes around 30 seconds to find out that it doesn't even compile. [ ... lots of trivial to fix warnings and errors ... ] Tell you what, I'll fix these and post a patch. Will that make you guys happy? This crap is *s* trivial to fix, it's easier to fix than to watch you guys bitch about it not being fixable. Will it be runnable (as in tested), rather than a compile-only fix? compile-only would be a good state to leave the code in the attic. -- juli mallett. email: [EMAIL PROTECTED]; aim: bsdflata; efnet: juli; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
i have yet to see a cisco ios image supporting ipv6 that was usable in production environment. and i have tried hard. This is getting OT but on the subject of repelling users, they´re probably trying hard to repel their users to the vendor J boxen. but i will admit to not having seen apollo networking for over a decade. but i probably have not been looking very widely. I´ve made a sighting in 1996 if I remember correctly. For their sake, I hope that´s gone now. seems to me that one useful question is whether the netns code being there non-trivially complicates maintenance and/or reliability of other code, and can i compile or module it out if the bits it occupies really bothers me? This is probably the right question. Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Juli Mallett writes: This crap is *s* trivial to fix, it's easier to fix than to watch you guys bitch about it not being fixable. Will it be runnable (as in tested), rather than a compile-only fix? compile-only would be a good state to leave the code in the attic. Only if it kills this _really_ dumb debate. In time, it will no longer compile, and then the situation will be the same as just punting to the Attic without the fix. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Mark Murray wrote: Terry Lambert writes: Peter Wemm wrote: Terry: will you please check your facts? It takes around 30 seconds to find out that it doesn't even compile. [ ... lots of trivial to fix warnings and errors ... ] Tell you what, I'll fix these and post a patch. Will that make you guys happy? Will it be runnable (as in tested), rather than a compile-only fix? Is tested a requirement fo code to be committed or to have it stay in the tree? Be careful of your answer, unless you are willing to remove all code that does not meet that criteria... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Terry Lambert writes: Mark Murray wrote: Will it be runnable (as in tested), rather than a compile-only fix? Is tested a requirement fo code to be committed or to have it stay in the tree? Both. Be careful of your answer, unless you are willing to remove all code that does not meet that criteria... Be careful of your interpretation of my answer. State _all_ your premises, and be careful not to use any undeclared ones. Do not hold me to any premise that I have not agreed to. All broken code needs to be fixed XOR removed. All fixes need to be tested. All code in the tree needs to be tested often to ensure that it is not broken. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Petri Helenius wrote: seems to me that one useful question is whether the netns code being there non-trivially complicates maintenance and/or reliability of other code, and can i compile or module it out if the bits it occupies really bothers me? This is probably the right question. As people keep pointing out, the code has been disabled since 1996, so it doesn't complicate maintenance, because maintenance hasn't been being done, even though it's trivially easy. What pisses me off about this is that people have been breaking API's out from under code, in such a way that no one who is not highly domain knowledgable can unbreak the code that they did not maintain. An API is a contract between pieces of code. If you break that contract, then you are responsible for fixing every piece of code that uses the contract. If people actually did this (they *don't*), THEN leaving the code in would complicate maintenance. Please apply the patches I have posted to the list for netns. Thanks, -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Mark Murray wrote: Only if it kills this _really_ dumb debate. In time, it will no longer compile, and then the situation will be the same as just punting to the Attic without the fix. Only if some idiot breaks the API contract again. Whatever happened to you broke it, you fix it? Hopefully, the next time it happens, and something gets punted to the Attic, it will be code *you* care about, instead of code I care about. Then it will be *your* problem, and I can sit back and make smarmy postings. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Mark Murray wrote: Terry Lambert writes: Mark Murray wrote: Will it be runnable (as in tested), rather than a compile-only fix? Is tested a requirement fo code to be committed or to have it stay in the tree? Both. Cool. Then I have a long list of things that can be fixed or removed. This whole thing about netns started 3 days ago. How many days after code is questioned does someone have to fix it before it is it OK to dike it out? Be careful of your answer, unless you are willing to remove all code that does not meet that criteria... Be careful of your interpretation of my answer. State _all_ your premises, and be careful not to use any undeclared ones. Do not hold me to any premise that I have not agreed to. All broken code needs to be fixed XOR removed. All fixes need to be tested. All code in the tree needs to be tested often to ensure that it is not broken. Let' start wth the libalias/natd incremental checksum update code; the code is based on RFC1141, instead of RFC1624. As a result, it get updated incorrectly occasionally, because it's using two's complement instead of one's complement math. Per RFC1642: RFC 1141 yields an updated header checksum of -0 when it should be +0. This is because it assumed that one's complement has a distributive property, which does not hold when the result is 0 (see derivation of [Eqn. 2]). People see this as hands on FTP installs, etc., going through FreeBSD based NAT's. It's very obvious ad easy to repeat: 1) Put a printf in tcp_input.c that compalins when the checksum is incorect. 2) Do a CVSup from that machine through a FreeBSD NAT How long can this remain unfixed before the code is diked out, and the checksum is recalculated fully, instead? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
De: Terry Lambert [EMAIL PROTECTED] [ Data: 2003-03-05 ] [ Subjecte: Re: Removal of netns - politically correct version ] On the other hand, there's no compelling reason to dike it out, if it can be made to work. I would argue that ISA support is more or less just as obsolete, as is 486 support, as is the F00F bug workaround, as is ... a lot of code that's still there. ISA support is not obsolete. All new PCs still have ISA busses. They might not have ISA Expansion Bus Slots, but they all[*] still connect their serial ports, parallel ports, and mouse/keyboard ports via ISA. Warner [*] well, except for the legacy free ones, which aren't many. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
M. Warner Losh wrote: ISA support is not obsolete. All new PCs still have ISA busses. They might not have ISA Expansion Bus Slots, but they all[*] still connect their serial ports, parallel ports, and mouse/keyboard ports via ISA. Not to mention i8254 which gets to be major pain if ACPI would not be an option. Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Mike Barcroft wrote: Terry Lambert [EMAIL PROTECTED] writes: Tim Robbins wrote: Is there a compelling reason why I shouldn't remove netns? That is, does it serve a purpose now that it could not serve if it was moved to the Attic? Might as well move /sys/i386/conf/GENERIC to the attic while you are at it. It can serve it's purpose from there, too. This comment is not helpful. Then let me politically correct it. I am cynical about the ability of any code to serve the same purpose from the Attic which it serves in the main source tree. What of the rest of my comment, which you removed? I'll rephrase that, too: Is there a compelling reason for removing this working code to the Attic? I am cynical that any purpose is served by making this change; my cynicism leads me to believe that the intention of it is to make it easier for someone to hack up other code which uses related API's, without having to hack up the netns code as well. In other words, it is being done to avoid maintenance, so that code changes may be hurried into the source tree. This upsets me, in that it seems to me that if someone makes an API change in one place, and avoids it in another, then the person who best understands the API change will be later unavailable to correct the code in which they avoided making the change. This is because, by avoiding the change in the first place, they have expressed a disinterest in making the change in the code in question. I would feel much more comfortable, were mainting older code, rather than diking it out, made part of the cost associated with making the API change in question. In other words, in order to write new code, it is sometimes necessary to maintain old code, and that maintenance is part of the price you must pay to the project in order to have your new code accepted. If this can not be accomplished, then I would submit that the new code be documented sufficiently before the dikeing out of the older code, such that someone else may take on the task of converting the code. Further, I suggest that there be some collaboration between the person making the changes, and anyone who wants to step forward in defense of the older code, such that there is an opportunity to correct the old code before it is diked out. In other words, it seems to me that the dike out is a first strike attack on code which will not LINT, following changes which are currently stored in someone local source tree, and the intent here is to dike out the code, and quickly follow it up with a set of commits which will kill it. Thus preventing it from serving it's same purpose from the Attic. Practically, and historically, it seems that there are a lot of instances, recently, of code being diked out, not because it is not currently working, but because someone wished to avoid maintaining it in the face of some sweeping change or new idea they want to push into the project. Or if you prefer an analogy: it is one thing for bits to rot; it is another thing altogether to intentionally spray them with Agent Orange. Regards, -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Terry Lambert [EMAIL PROTECTED] writes: Mike Barcroft wrote: Terry Lambert [EMAIL PROTECTED] writes: Tim Robbins wrote: Is there a compelling reason why I shouldn't remove netns? That is, does it serve a purpose now that it could not serve if it was moved to the Attic? Might as well move /sys/i386/conf/GENERIC to the attic while you are at it. It can serve it's purpose from there, too. This comment is not helpful. Then let me politically correct it. This is much more useful, since you document your assertions which turn out to be incorrect (see below). I am cynical about the ability of any code to serve the same purpose from the Attic which it serves in the main source tree. What of the rest of my comment, which you removed? I'll rephrase that, too: Is there a compelling reason for removing this working code to the Attic? Yes, the compelling reason is that it is broken and no one has stepped forward to fix it. Tim is trying to ascertain whether there are infact real users of this. Real users would either have big patchsets or very old versions of FreeBSD. I am cynical that any purpose is served by making this change; my cynicism leads me to believe that the intention of it is to make it easier for someone to hack up other code which uses related API's, without having to hack up the netns code as well. The LINT option for Xerox NS protocols has been commented out since at least 1996. It's very unlikely there are actual FreeBSD users of said protocol. In other words, it is being done to avoid maintenance, so that code changes may be hurried into the source tree. No, Tim's goal is to clean up the tree and remove unused code, or find maintainers for broken code that indeed has users. [other comments based on false assertions removed.] Practically, and historically, it seems that there are a lot of instances, recently, of code being diked out, not because it is not currently working, but because someone wished to avoid maintaining it in the face of some sweeping change or new idea they want to push into the project. I think most people just don't want to have to maintain code that no one uses. The only way we can figure out if anyone's using the code is to ask. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Terry Lambert wrote: Is there a compelling reason for removing this working code to the Attic? Terry: will you please check your facts? It takes around 30 seconds to find out that it doesn't even compile. In file included from ../../../netns/idp_usrreq.c:51: ../../../netns/ns_pcb.h:82: warning: function declaration isn't a prototype ../../../netns/idp_usrreq.c:67: warning: return type defaults to `int' ../../../netns/idp_usrreq.c:67: warning: function declaration isn't a prototype ../../../netns/idp_usrreq.c: In function `idp_input': ../../../netns/idp_usrreq.c:83: incompatible types in assignment ../../../netns/idp_usrreq.c:83: structure has no member named `ifa_next' ../../../netns/idp_usrreq.c:101: warning: `return' with no value, in function returning non-void ../../../netns/idp_usrreq.c: At top level: ../../../netns/idp_usrreq.c:107: warning: return type defaults to `int' ../../../netns/idp_usrreq.c:107: warning: function declaration isn't a prototype ../../../netns/idp_usrreq.c: In function `idp_abort': ../../../netns/idp_usrreq.c:111: warning: implicit declaration of function `ns_pcbdisconnect' ../../../netns/idp_usrreq.c: At top level: ../../../netns/idp_usrreq.c:120: warning: function declaration isn't a prototype ../../../netns/idp_usrreq.c:141: warning: return type defaults to `int' ../../../netns/idp_usrreq.c:141: warning: function declaration isn't a prototype ../../../netns/idp_usrreq.c: In function `idp_output': ../../../netns/idp_usrreq.c:150: warning: nested extern declaration of `idpcksum' ../../../netns/idp_usrreq.c:184: warning: address of register variable `m' requested ../../../netns/idp_usrreq.c:200: too many arguments to function `ns_cksum' ../../../netns/idp_usrreq.c:209: warning: implicit declaration of function `ns_output' ../../../netns/idp_usrreq.c: At top level: ../../../netns/idp_usrreq.c:258: warning: return type defaults to `int' ../../../netns/idp_usrreq.c:258: warning: function declaration isn't a prototype ../../../netns/idp_usrreq.c: In function `idp_ctloutput': ../../../netns/idp_usrreq.c:266: warning: nested extern declaration of `ns_pexseq' ../../../netns/idp_usrreq.c: At top level: ../../../netns/idp_usrreq.c:369: warning: return type defaults to `int' ../../../netns/idp_usrreq.c:369: warning: function declaration isn't a prototype ../../../netns/idp_usrreq.c: In function `idp_usrreq': ../../../netns/idp_usrreq.c:377: warning: implicit declaration of function `ns_control' ../../../netns/idp_usrreq.c:394: warning: implicit declaration of function `ns_pcballoc' ../../../netns/idp_usrreq.c:407: warning: implicit declaration of function `ns_pcbdetach' ../../../netns/idp_usrreq.c:411: warning: implicit declaration of function `ns_pcbbind' ../../../netns/idp_usrreq.c:423: warning: implicit declaration of function `ns_pcbconnect' ../../../netns/idp_usrreq.c:493: warning: implicit declaration of function `ns_setsockaddr' ../../../netns/idp_usrreq.c:497: warning: implicit declaration of function `ns_setpeeraddr' ../../../netns/idp_usrreq.c: At top level: ../../../netns/idp_usrreq.c:531: warning: return type defaults to `int' ../../../netns/idp_usrreq.c:531: warning: function declaration isn't a prototype ../../../netns/idp_usrreq.c: In function `idp_raw_usrreq': ../../../netns/idp_usrreq.c:537: warning: nested extern declaration of `nsrawpcb' ../../../netns/idp_usrreq.c:543: `SS_PRIV' undeclared (first use in this function) ../../../netns/idp_usrreq.c:543: (Each undeclared identifier is reported only once ../../../netns/idp_usrreq.c:543: for each function it appears in.) In file included from ../../../netns/ns.c:40: ../../../sys/ioctl.h:47:2: #warning Don't #include ioctl.h in the kernel. Include xxxio.h instead. In file included from ../../../netns/ns_error.c:49: ../../../netns/ns_pcb.h:82: warning: function declaration isn't a prototype ../../../netns/ns_error.c:66: warning: return type defaults to `int' ../../../netns/ns_error.c:66: warning: function declaration isn't a prototype ../../../netns/ns_error.c:91: warning: return type defaults to `int' ../../../netns/ns_error.c:91: warning: function declaration isn't a prototype ../../../netns/ns_error.c: In function `ns_error': ../../../netns/ns_error.c:98: warning: nested extern declaration of `idpcksum' ../../../netns/ns_error.c:107: warning: implicit declaration of function `ns_echo' ../../../netns/ns_error.c:108: warning: `return' with no value, in function returning non-void ../../../netns/ns_error.c:159: too many arguments to function `ns_cksum' ../../../netns/ns_error.c:162: warning: implicit declaration of function `ns_output' ../../../netns/ns_error.c: At top level: ../../../netns/ns_error.c:169: warning: return type defaults to `int' ../../../netns/ns_error.c:169: warning: function declaration isn't a prototype ../../../netns/ns_error.c:186: warning: return type defaults to `int' ../../../netns/ns_error.c:186: warning: function declaration isn't a prototype ../../../netns/ns_error.c: In function
Re: Removal of netns - politically correct version
In message [EMAIL PROTECTED], Peter Wemm writes: Terry Lambert wrote: Is there a compelling reason for removing this working code to the Attic? Terry: will you please check your facts? It takes around 30 seconds to find out that it doesn't even compile. Could we possibly move Terry to the attic too ? Please ? Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | 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-current in the body of the message
Re: Removal of netns - politically correct version
Peter Wemm wrote: Terry Lambert wrote: Is there a compelling reason for removing this working code to the Attic? Terry: will you please check your facts? It takes around 30 seconds to find out that it doesn't even compile. [ ... lots of trivial to fix warnings and errors ... ] Tell you what, I'll fix these and post a patch. Will that make you guys happy? This crap is *s* trivial to fix, it's easier to fix than to watch you guys bitch about it not being fixable. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
* De: Terry Lambert [EMAIL PROTECTED] [ Data: 2003-03-04 ] [ Subjecte: Re: Removal of netns - politically correct version ] Peter Wemm wrote: Terry Lambert wrote: Is there a compelling reason for removing this working code to the Attic? Terry: will you please check your facts? It takes around 30 seconds to find out that it doesn't even compile. [ ... lots of trivial to fix warnings and errors ... ] Tell you what, I'll fix these and post a patch. Will that make you guys happy? This crap is *s* trivial to fix, it's easier to fix than to watch you guys bitch about it not being fixable. Terry, watch your language. And then find me a site running XNS that expects to be running a current version of FreeBSD, or ideally someone I could peer an XNS system with if I were to take up maintainership of it? You have until the code is gone from CVS, which hopefully will be very soon. Thanx, juli. PS: I might be interested in getting it out of the attic if you could find me a good place for XNS-only connectivity, with IP-over-XNS of some sort so I could still IRC. -- juli mallett. email: [EMAIL PROTECTED]; aim: bsdflata; efnet: juli; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
On Tue, 4 Mar 2003, Terry Lambert wrote: Tell you what, I'll fix these and post a patch. Will that make you guys happy? Yes, as will anything else that cuts down on the metadiscussions and increases the quality of the codebase. mcl To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
* De: Mark Linimon [EMAIL PROTECTED] [ Data: 2003-03-04 ] [ Subjecte: Re: Removal of netns - politically correct version ] On Tue, 4 Mar 2003, Terry Lambert wrote: Tell you what, I'll fix these and post a patch. Will that make you guys happy? Yes, as will anything else that cuts down on the metadiscussions and increases the quality of the codebase. No, it screws up the quality of the codebase if it cannot be tested and used every day, and I doubt Terry will be doing real testing. HOWEVER, I am willing to keep netns working if someone can provide a pure XNS with IP-over-XNS provider. Playing around using multiple FreeBSD boxen with a possibly broken but interoperable implementation is also out of the question, as nobody uses it. For things that people actually use, it's OK as prototyping fixes and getting them in tree, and then the users can find where it's broken later. -- juli mallett. email: [EMAIL PROTECTED]; aim: bsdflata; efnet: juli; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[PATCH] make netns compile cleanly (was Re: Removal of netns - politically correct version
Terry Lambert wrote:
Peter Wemm wrote:
Terry: will you please check your facts? It takes around 30 seconds
to find out that it doesn't even compile.
[ ... lots of trivial to fix warnings and errors ... ]
Tell you what, I'll fix these and post a patch. Will that make you
guys happy?
This crap is *s* trivial to fix, it's easier to fix than
to watch you guys bitch about it not being fixable.
Here are two patches. The first fixes missing pieces in /sys/conf/files
and /sys/conf/options, the second fixes all the files that need it in
/sys/netns/.
It's now possible to add:
options NS
to a kernel config, and still get a kernel that does it's thing.
Note that I did not go through and made the protosw[] changes,
so there's some initialization warnings there, but by my clock,
I only spent an hour on the thing, and what you guys were bitching
about was it doesn't even compile.
If you want that fixed too, then it's an easy fix, using the IPX
sources as a guide, since IPX is derives from XNS.
-- TerryIndex: files
===
RCS file: /usr/cvs/src/sys/conf/files,v
retrieving revision 1.340.2.87
diff -c -r1.340.2.87 files
*** files 19 Dec 2001 20:59:27 - 1.340.2.87
--- files 5 Mar 2003 00:49:18 -
***
*** 923,928
--- 923,929
netns/ns_output.c optional ns
netns/ns_pcb.coptional ns
netns/ns_proto.c optional ns
+ netns/ns_cksum.c optional ns
netns/spp_debug.c optional ns
netns/spp_usrreq.coptional ns
nfs/nfs_bio.c optional nfs
Index: options
===
RCS file: /usr/cvs/src/sys/conf/options,v
retrieving revision 1.191.2.37
diff -c -r1.191.2.37 options
*** options 3 Nov 2001 01:41:07 - 1.191.2.37
--- options 4 Mar 2003 22:10:11 -
***
*** 272,277
--- 272,278
TCPDEBUG
TCP_DROP_SYNFIN opt_tcp_input.h
XBONEHACK
+ NSopt_ns.h
# Netgraph(4). Use option NETGRAPH to enable the base netgraph code.
# Each netgraph node type can be either be compiled into the kernel
Index: idp_usrreq.c
===
RCS file: /usr/cvs/src/sys/netns/idp_usrreq.c,v
retrieving revision 1.9
diff -c -r1.9 idp_usrreq.c
*** idp_usrreq.c28 Aug 1999 00:49:47 - 1.9
--- idp_usrreq.c5 Mar 2003 01:15:42 -
***
*** 54,59
--- 54,63
#include netns/idp_var.h
#include netns/ns_error.h
+ extern int idpcksum; /* from ns_input.c */
+ extern long ns_pexseq;/* from ns_input.c */
+ extern struct nspcb nsrawpcb; /* from ns_input.c */
+
/*
* IDP protocol implementation.
*/
***
*** 63,68
--- 67,73
/*
* This may also be called for raw listeners.
*/
+ void
idp_input(m, nsp)
struct mbuf *m;
register struct nspcb *nsp;
***
*** 79,92
idp_ns.sns_addr = idp-idp_sna;
if (ns_neteqnn(idp-idp_sna.x_net, ns_zeronet) ifp) {
register struct ifaddr *ifa;
! for (ifa = ifp-if_addrlist; ifa; ifa = ifa-ifa_next) {
if (ifa-ifa_addr-sa_family == AF_NS) {
idp_ns.sns_addr.x_net =
IA_SNS(ifa)-sns_addr.x_net;
break;
}
! }
}
nsp-nsp_rpt = idp-idp_pt;
if ( ! (nsp-nsp_flags NSP_RAWIN) ) {
--- 84,99
idp_ns.sns_addr = idp-idp_sna;
if (ns_neteqnn(idp-idp_sna.x_net, ns_zeronet) ifp) {
register struct ifaddr *ifa;
+ int s;
! s = splimp();
! TAILQ_FOREACH(ifa, ifp-if_addrhead, ifa_link)
if (ifa-ifa_addr-sa_family == AF_NS) {
idp_ns.sns_addr.x_net =
IA_SNS(ifa)-sns_addr.x_net;
break;
}
! splx(s);
}
nsp-nsp_rpt = idp-idp_pt;
if ( ! (nsp-nsp_flags NSP_RAWIN) ) {
***
*** 103,108
--- 110,116
m_freem(m);
}
+ void
idp_abort(nsp)
struct nspcb *nsp;
{
***
*** 134,153
so-so_error = errno;
ns_pcbdisconnect(nsp);
soisdisconnected(so);
}
int noIdpRoute;
idp_output(nsp, m0)
struct nspcb *nsp;
struct mbuf *m0;
{
! register struct mbuf *m;
register struct idp *idp;
register struct socket *so;
register int len = 0;
register struct route *ro;
! struct mbuf *mprev;
! extern int idpcksum;
/*
* Calculate data length.
--- 142,163
so-so_error = errno;
ns_pcbdisconnect(nsp);
Re: Removal of netns - politically correct version
Terry Lambert wrote: Peter Wemm wrote: Terry Lambert wrote: Is there a compelling reason for removing this working code to the Attic? Terry: will you please check your facts? It takes around 30 seconds to find out that it doesn't even compile. [ ... lots of trivial to fix warnings and errors ... ] Tell you what, I'll fix these and post a patch. Will that make you guys happy? Not really. I'd like to see a relevant demonstration of it working with another relevant networking system [that does NOT speak some other common protocol such as IP or IPX] that shows that it is worth keeping this baggage around. No, I'm not interested in some DOS-2.11 floppy disks you have had sitting untouched in a drawer for 10 years. ie: Show that it is worth something to the project to keep it. This was only revived last time because somebody promised to maintain it. And as you can see, for the last 7 years it hasn't been missed. The point wasn't that it doesn't compile, rather nobody gave a damn that it didn't compile for 7 years. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] make netns compile cleanly (was Re: Removal of netns - politically correct version
Terry Lambert wrote: Terry Lambert wrote: Peter Wemm wrote: Terry: will you please check your facts? It takes around 30 seconds to find out that it doesn't even compile. [ ... lots of trivial to fix warnings and errors ... ] Tell you what, I'll fix these and post a patch. Will that make you guys happy? This crap is *s* trivial to fix, it's easier to fix than to watch you guys bitch about it not being fixable. Here are two patches. The first fixes missing pieces in /sys/conf/files and /sys/conf/options, the second fixes all the files that need it in /sys/netns/. You seem to have posted the wrong patch. This is against 4.x, not -current, and this is [EMAIL PROTECTED] Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
