Date: Fri, 16 Jun 2006 12:18:37 -0700 From: Doug Barton <dougb@FreeBSD.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: arch@FreeBSD.org Subject: Re: MFC of socket/protocol reference improvements Message-ID: <4493040D.7020707@FreeBSD.org> In-Reply-To: <20060616194310.M742@fledge.watson.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4493040D.7020707>