>Out of curiosity, in what ways has OpenBSD deviated from POSIX? And
>what
>makes it so difficult for developers to port software to the platform?
Oh boy.
My OpenBSD test platform has an old version of OpenBSD, so things
might have changed lately, but the way OpenBSD has evolved in the past
makes me say it's unlikely. Here are my experiences with porting to
OpenBSD; all of these were true with an OpenBSD version a few years old,
and are probably still true today.
- OpenBSD is, by far, the OS I need to have the most workarounds for
when
attempting to write POSIX code. The amount of POSIX breakage in the
system headers and libraries is the highest I've seen - higher than
MacOS,
which is second, and FreeBSD, which is third - and most of that breakage
is about very stupid things that could be easily fixed if there was a
will
to it; the mere existence of those issues shows that the devs just don't
care. Among others:
+ it does not define EPROTO
+ it needs a specific feature test macro to define EOVERFLOW
+ it also needs specific feature test macros to define certain POSIX
functions - I don't remember exactly which, but I distinctly remember
having to add a lot of boilerplate to a few files in order to build on
OpenBSD when I was only using POSIX functions.
+ not all libc headers are self-contained (they have improved a lot on
that point lately, but it's still not perfect)
- Unless it has been changed lately, OpenBSD purposely breaks POSIX in
is implementation of pselect() and generally timeouts defined via a
struct timespec. It makes the system call *fail* with EINVAL if the
given timeout is longer than 1e8 seconds.
It could accept long timeouts, which is the correct, standardized, and
sensible thing to do.
It could arguably cap timeouts at 1e8 seconds and make pselect() return
0
if no event happens during all this time.
But no, it chooses to *break* programs using long timeouts, by making
the
system call fail. This is the worst possible solution to a problem that
only exists in OpenBSD developers' minds.
This breaks skalibs' model of infinite timeouts (implemented via
something like 2^60 seconds). As a result, skarnet.org programs that
use timeouts simply do not work on versions of OpenBSD that exhibit this
bug. It would be possible to work around it, but so far I haven't heard
enough complaints - and the few complaints I've had I've redirected to
the
OpenBSD devs where they belong.
- The OpenBSD developers like to do things their own way with no regard
for the rest of the world. This is a good attitude to have in some
contexts, and not so good in other contexts - but they do not know the
difference. So, when it's about providing functionality that's not
standardized (and in a few cases, even when equivalent functionality has
actually been standardized), OpenBSD often takes a different route than
other systems, sometimes gratuitously. This increases the portability
efforts for developers. Example: the arc4random() family of functions
is a good API; all BSDs (including MacOS) provide it; but OpenBSD is the
only one *not* to provide arc4random_addrandom(), which caused the
initial issue in this thread.
If the OpenBSD devs deem it useless or harmful to provide a way for
users
to add to the system's entropy pool, maybe they're right, maybe their
point of view is valid - but the sensible, play-nice-with-others
solution
would be to still provide an arc4random_addrandom() function and
implement
it as a NOP. But who cares about playing nice with others when you can
simply remove the interfaces you don't like, right?
- About implementations: anyone who still believes that OpenBSD devs
pay
attention to quality of implementation should read
http://www.tedunangst.com/flak/post/select-works-poorly
This does not impact me as a developer, but it is still appalling.
Couple that to the slowness of OpenBSD's malloc() (which performs a
shitload of system calls) and a few other usability issues, and it
becomes hard to recommend OpenBSD as a viable Unix platform, despite
its much-touted (and imho excessively so) security.
I'm not even counting the quirkiness of OpenBSD's implementation of
ancillary data (i.e. data passed across Unix sockets via a struct
msghdr,
such as fd-passing), because on this one FreeBSD takes the cake. Making
the unixmessage_* functions work on the BSDs was a trip to hell and
back,
but OpenBSD wasn't the main antagonist here - for once.
>Does the deviation in API directly cause any issues for s6 and other
>applications built on top of skalibs, or does skalibs manage to hide
>most
>of the differences?
skalibs hides most of the differences, at a non-negligible cost in the
form of developer time and code bloat for the workarounds - most of
which
do not impact run-time performance, but some of which do, notably for
fd-passing.
The timeout bug currently causes direct issues for s6 and anything
using skalibs' iopause(). It would be possible to hide that one
too, for more maintenance cost.
> If Laurent were to terminate support for OpenBSD would
>it still be possible to run the s6 suite so long as a suitably patched
>version of skalibs was available to compile against?
The OpenBSD people have a cathedral development model, which makes
sense
in the context of a security-oriented Unix platform. The drawback is
that
in order for a piece of software to seamlessly integrate with OpenBSD,
it
needs to adapt to the OpenBSD way of doing things. In other words,
OpenBSD
is as much about policy as it is about mechanism. And so, OpenBSD
integration is best performed, not by package authors, but by OpenBSD
maintainers, who take a "regular POSIX" piece of software and maintain a
"make it work on our system" set of patches.
The best solution would be to find a friendly OpenBSD developer (talk
about unicorns) willing to maintain a port of skarnet.org software that
follows all the OpenBSD policies and quirks. Without that, if I drop
support, it won't be two OpenBSD releases before skalibs stops building
-
because *they just don't care*.
--
Laurent
Received on Sat Feb 18 2017 - 06:40:45 UTC