Date: Sun, 27 Apr 1997 14:23:46 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Garrett Wollman <wollman@FreeBSD.org> Cc: CVS-committers@FreeBSD.org, cvs-all@FreeBSD.org, cvs-sys@FreeBSD.org Subject: Re: cvs commit: src/sys/net if.c raw_cb.c raw_cb.h raw_usrreq.c rtsock.c src/sys/kern sys_socket.c uipc_domain.c uipc_proto.c uipc_socket.c uipc_socket2.c uipc_syscalls.c uipc_usrreq.c src/sys/netinet in.c in_pcb.c in_pcb.h in_proto.c in_var.h ip_output.c ip_var.h raw_ip.c tcp_input.c tcp_usrreq.c tcp_var.h udp_usrreq.c src/sys/nfs nfs_socket.c nfs_syscalls.c src/sys/sys protosw.h socketvar.h un.h Message-ID: <4753.862176226@time.cdrom.com> In-Reply-To: Your message of "Sun, 27 Apr 1997 13:01:31 PDT." <199704272001.NAA21898@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> The long-awaited mega-massive-network-code- cleanup. Part I. > > This commit includes the following changes: > 1) Old-style (pr_usrreq()) protocols are no longer supported, the compatibi This commit worries the snot out of me - please reassure me that my fears are unfounded. Basically, if I read the extent of your changes correctly (and perhaps I'm not) I can just see the following scenario developing: I get a call from someone like Tony Ardolino at Netcon Inc, the people who use a highly hacked FreeBSD netns to provide the Novell IPX gateway/server/client software for FreeBSD. This call, since it's Tony on the other end and he's a self-confessed, hot-headed Italian type who starts reaching for the sawed-off shotgun when these things happen, is both irate and unproductive. I point out to Tony that he agreed to give us back changes and support this code in FreeBSD, and that now would be an excellent time to do this (I actually send him this exact email about 2 weeks ago when I first heard about it, as sort of a "heads up"). Tony responds that he doesn't have to do stuff like this for AIX or Solaris, he's got 11 different UNIX platforms to support and yes, goddamn it, he can't possibly get into the internals of each and every one whenever the maintainers show themselves to be completely insensitive to their vendors' needs and do something that's not backwards compatible, it's an outrage, they didn't do things like that back in his day (the 1820s, special assistant to Charles Babbage at Cambridge), and yadda yadda yadda scream wail fume yadda yadda yada. On the final analysis, there's no "right" person in this debate, either. If we play hard line, Tony takes his ball and goes home in disgust, muttering to anyone who'll listen about what a bunch of unprofessional children the FreeBSD folks are. The people who've actually purchased Netcon for FreeBSD (or wish to purchase it in the future) are the ultimate losers and we, in turn, start looking like a bunch of elitist idiots who would choose to screw their users over making any kind of accomodation with a vendor. Tony, on the other hand, could also make due on his promise (and I'm sure he's got more than one platform to support - this may have even been a FOOLISH promise for him to make, but he still made it :-) and try to work with us, avoiding all potential bloodshed and forging some stronger ties with the project in the process. The reality of the situation is, however, that nobody's going to run all the way to the other end of the field and some halfway measures are going to have to happen if, as I said, my fears about this are not unfounded. Assuming that this is a developing situation, would it perhaps be too unreasonable to hope that someobody (you, ideally) with good experience in networking and a knowledge of exactly what sorts of issues Tony is going to need to deal with to "catch up" to 3.0 actually CALL Tony first? That would make major points, and during this call the point could also be strongly made that this is NOT even going to affect his business until late in '97 since 2.2 does not have this change and he can continue to sell the same Netcon product through all of 2.2.x's lifecycle. The fact that we were actually concerned enough about this to give him close to a year's lead time on the issue should be enough demonstrated concern to get through whatever initial unwillingness that he may have. This is also not a suggestion that we kiss every somewhat difficult vendor's ass everytime a situation like this comes up, simply that we demonstrate a _professional degree of concern_ for issues which effect not just vendors, but the users of those vendors' products. Essentially, since these products are running under FreeBSD then we should consider ourselves more "partners" in these situations rather than simply "going adversarial" with the vendor, fighting him or her every step of the way as we try and make forward progress. That, as Beevis would say, sucks. Comments? Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4753.862176226>