From owner-freebsd-arch@FreeBSD.ORG Fri Jun 16 19:18:39 2006 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3F9016A47C for ; Fri, 16 Jun 2006 19:18:39 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id D056643D46 for ; Fri, 16 Jun 2006 19:18:38 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 3004 invoked by uid 399); 16 Jun 2006 19:18:38 -0000 Received: from localhost (HELO ?192.168.0.6?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 16 Jun 2006 19:18:38 -0000 Message-ID: <4493040D.7020707@FreeBSD.org> Date: Fri, 16 Jun 2006 12:18:37 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Robert Watson References: <20060611141632.Y26634@fledge.watson.org> <20060615175853.Y52950@carver.gumbysoft.com> <20060616102458.N742@fledge.watson.org> <4492FB95.9050606@FreeBSD.org> <20060616194310.M742@fledge.watson.org> In-Reply-To: <20060616194310.M742@fledge.watson.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org Subject: Re: MFC of socket/protocol reference improvements X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 19:18:39 -0000 Robert Watson wrote: > So I'm not just looking for objection on principle, I'm looking for > objection based on practice: do we know of third parties extending the > kernel with this KPI who distribute their work and will be affected by > this in ways that make it difficult for them to maintain their > component? Remember that if they compile their module against the > updated kernel, they will get warnings indicating the KPI changes have > taken place, since the prototypes of the affected protosw entries will > change. First off, it's entirely possible that my knowledge of the programming issues involved is not sufficient to make an intelligent judgment on this topic. If that's the case here, I apologize for wasting everyone's time. That said however, I reject your hypothesis that a third party developer who is depending on the status quo has to make themselves known before you're willing to reconsider changing things in RELENG_6. There are any number of reasons why this might be impossible or undesirable, not the least of which is that no one from that vendor is subscribed to -arch. On a more fundamental level, what I'm asking for is a clear bright line, and what you're saying is that it's ok for the line to be fuzzy, where some things can always be changed because they don't affect anyone we know about, other things can sometimes be changed if the pain is minimal, etc. I fully concede that from a developer standpoint, you might be right, and you're in a much better position than I to make that call. However from a business standpoint (and I am forced to where my businessman hat more than my developer hat nowadays, c'est la vie), clear bright lines are good, and fuzzy lines that depend on the (perceived) whims of people I don't know and don't have any authority over are bad. Doug -- This .signature sanitized for your protection