Re: [RFC][PATCH] _UC_TLSBASE for all ports

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> [...], or simply say "tough, it will not work on NetBSD because we
>> refuse to compromise".

> IMO here it is even a worse stance, since we already have the desired
> fix for amd64, i386, m68k, mips, vax, and hppa.

Ah, but is it really a fix?

IMO this all hinges on just what the interface contract for the
*context calls is.  Depending on that, I can see this as being any of
various possibilities ("you" here is the code mentioned upthread
(glusterfs?) that assumes something about these calls):

(a) "Linux is broken; you're taking advantage of a bug".

(b) "You're using the call outside its interface spec; you're off in
    undefined-behaviour weeds."

(c) "Any of the various behaviours are permitted; none of the
    implementations are broken, and you're depending on unspecified
    behaviour."

(d) "NetBSD ports $LIST are broken; we need to fix them."

Given what manu@ has said about standards, we have to either consider
that there exists no de-jure spec, or we have to depend on a past spec.
Personally, I'd be inclined to do the latter; if we were to do the
former, we should remove the functions altogether, it seems to me.

If we do depend on a past spec, then it depends on what it says.  If it
doesn't specify this, then the code is depending on an undocumented
aspect of the interface and, depending on how you want to squint your
mind, either is broken or is using an extension to the interface.  If
it does specify this, then we have a reference to decide whether the
code is broken or NetBSD is broken (or perhaps even both).

> It would be more like: "it will work on NetBSD, except for sh3,
> sparc, and sparc64 ports because we refuse to compromise.  And on
> powerpc and alpha it will work but with different interfaces".

Assuming we go with the "no spec" stance, I think the truth would be
more like "trying to use contexts across thread boundaries is
inherently MD, working the way you expect on ports $LIST1, working this
other way on ports $LIST2, and this third way on ports $LIST3; you're
depending on behaviour not portable between CPU architectures".

> We are supposed to focus on portability, it is really weird to argue
> that a feature should have a MI interface.

We already have lots of places where different ports differ for good
reasons, everything from not executing the same machine language to
different sizes for the same types to different floating-point formats.
If we consider that there is no spec, or it's silent on this point,
then this is depending on an accident of the implementation.

Of course, depending on how much NetBSD cares about glusterfs, we may
want to try to push fixes upstream, make ourselves compatible with its
usage patterns (whether that constitutes fixing, breaking, or neither
depends on which of the above stances applies), or ignore the issue and
let glusterfs be incompatible with NetBSD.  I don't really have a horse
in that race - I'm mostly trying to get people talking about the issues
here instead of basing their arguments on different assumptions and
thus talking past one another.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B