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
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
libalias/NAT incremental checksum (was Re: Removal of netns)
Mark Murray wrote: > > 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. This is not a argument over mere implmenetation semantics. The incremental checksum code is broken. Bad tcpchecksum - before: 0x38f3 after: 0x1802 Bad tcpchecksum - before: 0x2870 after: 0xe81e Bad tcpchecksum - before: 0x6319 after: 0x0608 Bad tcpchecksum - before: 0x369a after: 0x1212 Bad tcpchecksum - before: 0xd885 after: 0x0004 The packets do not get through, no matter how many times they are resent by the sender. The reason that the CVSup is successful is an artifact of the CVSup retry mechanism. People using other protocols, like FTP, or programs like "fetch" are well and truly screwed by this bug. -- 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
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
"> 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
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
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
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
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
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
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. -- 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
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
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
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
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
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
> > 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
* 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
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
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
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
> 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
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
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
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
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
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
* 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
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
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
On Wed, 5 Mar 2003, 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? netns could be safely moved to Attic. I'm receive enough IPX related questions, and never got any about XNS. netns stack was used by NetCon package which implemented TFS filesystem for NetWare connectivity. Guess, which protocol they used to communicate with servers ? Right, it was IPX. So, if netns were still supported it became just a parallel implementation of netipx. Last version of FreeBSD supported by NetCon was 2.2.X. Lack of support for FreeBSD 3.X encouraged me to write nwfs because it was necessary for my daily tasks. BTW, NetCon still offers their product for FreeBSD 2.2: http://www.netcon.com/download/download.htm -- Boris Popov http://rbp.euro.ru 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
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: Removal of netns
Darcy Buskermolen wrote: > I have at least 1 VPN setup that requires full IPX support. Yep, but keep in mind that netipx is different to netns. netipx actually works and is actually useful. > On Tuesday 04 March 2003 15:32, Chris Fowler wrote: > > What is IPX currently being used for? Legacy systems? > > > > I've been stuck in TCP/IP land for many years now. Have been lucky > > enough to not run into any IPX. > > > > On Tue, 2003-03-04 at 18:26, Tim Robbins wrote: > > > On Tue, Mar 04, 2003 at 02:53:56PM -0800, Julian Elischer wrote: > > > > I thought nwfs used it? > > > > > > nwfs uses netipx. From what I can tell, netipx was based on netns. > > > > > > > > > Tim > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > > with "unsubscribe freebsd-current" in the body of the message > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-net" in the body of the message > > --=20 > Darcy Buskermolen > Wavefire Technologies Corp. > ph: 250.717.0200 > fx: 250.763.1759 > http://www.wavefire.com > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > 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: Removal of netns
Julian Elischer wrote: > I thought nwfs used it? Nope. But actually looking at the code would have told you that. Remember, we're talking about the Xerox networking suite here. It's not like its a widely deployed protocol or something important. > > On Wed, 5 Mar 2003, 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? > > > > > > Tim > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-net" in the body of the message > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > 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
[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 #include + 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_pcbdisconn
Re: Removal of netns
I have at least 1 VPN setup that requires full IPX support. On Tuesday 04 March 2003 15:32, Chris Fowler wrote: > What is IPX currently being used for? Legacy systems? > > I've been stuck in TCP/IP land for many years now. Have been lucky > enough to not run into any IPX. > > On Tue, 2003-03-04 at 18:26, Tim Robbins wrote: > > On Tue, Mar 04, 2003 at 02:53:56PM -0800, Julian Elischer wrote: > > > I thought nwfs used it? > > > > nwfs uses netipx. From what I can tell, netipx was based on netns. > > > > > > Tim > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-current" in the body of the message > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message -- Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removal of netns
On Tue, Mar 04, 2003 at 01:35:51PM -0800, Terry Lambert wrote: > Things being removed constantly. > > If you will remember, there has been a rocky history with the > removal of functionality in FreeBSD. If you don't remember, > I will be happy to remind you of specific incidents that ended > up causing a lot of grief, most of which I was not involved in, > but merely watched from the sidelines. I'm hard-pressed to think of any change to FreeBSD that you have not involved yourself in ;-) Kris pgp0.pgp Description: PGP signature
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
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: 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
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
What is IPX currently being used for? Legacy systems? I've been stuck in TCP/IP land for many years now. Have been lucky enough to not run into any IPX. On Tue, 2003-03-04 at 18:26, Tim Robbins wrote: > On Tue, Mar 04, 2003 at 02:53:56PM -0800, Julian Elischer wrote: > > > I thought nwfs used it? > > nwfs uses netipx. From what I can tell, netipx was based on netns. > > > Tim > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removal of netns
On Tue, Mar 04, 2003 at 02:53:56PM -0800, Julian Elischer wrote: > I thought nwfs used it? nwfs uses netipx. From what I can tell, netipx was based on netns. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removal of netns
Julian Elischer (Tue, Mar 04, 2003 at 02:53:56PM -0800) wrote: > I thought nwfs used it? > > > On Wed, 5 Mar 2003, 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? That's netncp if I am not mistaken and thanks to Tim and Max Khon, it's now fixed, IIRC. Kudos to them. :-) -- 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
I thought nwfs used it? On Wed, 5 Mar 2003, 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? > > > Tim > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removal of netns
Wilko Bulte wrote: > On Tue, Mar 04, 2003 at 07:56:27AM -0800, Terry Lambert wrote: > > Is there a compelling reason for doing this, other than "I > > want to make some API/locking change, but I don't want to > > have to keep this code working at the same time"? Maximizing > > Is there a compelling reason for you to moan about the removal > of things constantly? Things being removed constantly. If you will remember, there has been a rocky history with the removal of functionality in FreeBSD. If you don't remember, I will be happy to remind you of specific incidents that ended up causing a lot of grief, most of which I was not involved in, but merely watched from the sidelines. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removal of netns
On Tue, 4 Mar 2003, Vincent Jardin wrote: > Why does it need to be removed ? According to me, it would be the same mistake > as the removal of netiso and netccitt. I did not know FreeBSD at this time, > but nowadays, in order to get an OS that supports many stacks, we have to use > NetBSD. If netns has so many users and our implementation has been broken for so long, why is it there hasn't been hordes of complaints? It appears as if users of netns are a rarity... > BSD4.4 was designed in order to support many stacks, FreeBSD 6, 7 ou 9 will > support only IPv4 and IPv6, won't they ? Today, widely-used networking applications use IPv4 and/or IPv6. It's understandable that as such, our IP stacks have gotten more testing and tuning than any other. If there's another networking protocol out there that has enough users interested and enough developer, vendor or device support, I don't see why it wouldn't be incorporated into the FreeBSD tree. A good example of a stack that was recently imported (comparatively speaking) would be Bluetooth. > I do not think that it needs to be removed. One should try to keep this > feature. As always, patches are welcome. If you happen to need netns for anything, scratch the itch... :-) Regards, > Andre Guibert de Bruet | Enterprise Software Consultant > > Silicon Landmark, LLC. | http://siliconlandmark.com/> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removal of netns
"Poul-Henning Kamp" wrote: > In message <[EMAIL PROTECTED]>, Vincent Jardin writes: > > >Why does it need to be removed ? According to me, it would be the same mista ke > >as the removal of netiso and netccitt. I did not know FreeBSD at this time, > >but nowadays, in order to get an OS that supports many stacks, we have to us e > >NetBSD. > > > >BSD4.4 was designed in order to support many stacks, FreeBSD 6, 7 ou 9 will > >support only IPv4 and IPv6, won't they ? > > We will import and retain any protocol stack which has enough interested > users and committers to keep it alive. > > netiso and netccitt both fell for both of those criteria: neither users > nor committers. > > netns fails both criteria too. Yep. It was removed in 1996 as well, because it didn't work. One company (Netcon) objected and claimed that they needed it for their commercial product and that they'd send fixes. Now, 7 years later, not a single person has shown the slightest interest in fixing it. It may as well have been left in the Attic the whole time. revision 1.7 date: 1996/10/17 18:42:19; author: jkh; state: Exp; lines: +3 -1 branches: 1.7.2; Bring back netns so that Netcon can take over support for it, as agreed. 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: 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
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
In message <[EMAIL PROTECTED]>, Vincent Jardin writes: >Why does it need to be removed ? According to me, it would be the same mistake >as the removal of netiso and netccitt. I did not know FreeBSD at this time, >but nowadays, in order to get an OS that supports many stacks, we have to use >NetBSD. > >BSD4.4 was designed in order to support many stacks, FreeBSD 6, 7 ou 9 will >support only IPv4 and IPv6, won't they ? We will import and retain any protocol stack which has enough interested users and committers to keep it alive. netiso and netccitt both fell for both of those criteria: neither users nor committers. netns fails both criteria too. -- 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
Why does it need to be removed ? According to me, it would be the same mistake as the removal of netiso and netccitt. I did not know FreeBSD at this time, but nowadays, in order to get an OS that supports many stacks, we have to use NetBSD. BSD4.4 was designed in order to support many stacks, FreeBSD 6, 7 ou 9 will support only IPv4 and IPv6, won't they ? I do not think that it needs to be removed. One should try to keep this feature. Regards, Vincent Le Mardi 4 Mars 2003 14:47, Tim Robbins a écrit : > 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? > > > Tim > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removal of netns
On Tue, Mar 04, 2003 at 07:56:27AM -0800, Terry Lambert wrote: > 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. > > Is there a compelling reason for doing this, other than "I > want to make some API/locking change, but I don't want to > have to keep this code working at the same time"? Maximizing Is there a compelling reason for you to moan about the removal of things constantly? -- | / o / /_ _ |/|/ / / /( (_) Bulte [EMAIL PROTECTED] 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
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
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. 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
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. Is there a compelling reason for doing this, other than "I want to make some API/locking change, but I don't want to have to keep this code working at the same time"? Maximizing bit-rot in order to avoid effort is a bad thing, particularly when it's done by the person who is making the change that causes the rot: that person is the person most qualified in the world to correct the bit-rot (or prevent it from happening), in that they have the best understanding of *why* their change broke something. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Removal of netns
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? Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message