svn commit: r241896 - in head: . cddl/contrib/opensolaris/lib/libzpool/common/sys share/man/man9 sys/cam/ctl sys/cddl/compat/opensolaris/kern sys/cddl/compat/opensolaris/sys sys/cddl/contrib/openso...

[Ben Kaduk]

On Tue, Nov 6, 2012 at 5:53 PM, Attilio Rao <attilio at freebsd.org> wrote:
> On Tue, Nov 6, 2012 at 10:50 PM, Ben Kaduk <minimarmot at gmail.com> wrote:
>> On Mon, Oct 22, 2012 at 1:50 PM, Konstantin Belousov <kib at freebsd.org> wrote:
> Hi Ben,
> no, ports/thirdy part should be adjusted on the -CURRENT ABI.
> Leaving MPSAFE would just leave confusion and a way to *not do* the conversion.

Hi Attilio,

I agree that port/thirdparty filesystems must be adjusted to the
-current ABI.  If the only change is ABI, not API, though, recompiling
is sufficient; no code changes are needed.
But the present state of affairs is that correct, working (MPSAFE)
code is broken, and there was no possibility to make it correct for
the new ABI prior to the ABI change.  It seems rather inconsiderate of
the users of -current (and we really want people to continue to run
-current!) to gratuitously break the API (well, KPI) as well as KBI,
when KPI change is not immediately necessary.  I must tell the user to
include "#define MPSAFE (0)" as a workaround until a patch can be
committed to the port, let alone the upstream!  The 10.0 release is a
bit off, yet; can we not spare a few months for lag between KBI change
and KPI change to allow third-parties who are paying attention to get
a smooth transition?  "Rebuild the port" is much easier than "observe
errors, dink around for a while investigating, patch the code, and
rebuild the port."
MPSAFE deorbit is a long-term project (which I am very happy to see
happen; thank you both Attilio and Kostantin and all!), but this step
seems rushed.  Why must KPI change occur in lockstep with KBI change?

-Ben