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...

[Attilio Rao]

On Tue, Nov 6, 2012 at 11:03 PM, Ben Kaduk <minimarmot at gmail.com> wrote:
> 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?

The point is that KPI/KBI of -CURRENT can change as long as
__FreeBSD_version is bumped (and if you really want to know my
opinion, I already see this as a forceful thing because it would not
be necessary in my mind, but I second the will of the majority of
developers). So, if the KPI/KBI changes all the thirdy part code,
ports and everything else must adapt.

MPSAFE flag is not any longer supported and code needs to be ported
appropriately to -CURRENT interface.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein