Deltas between FreeBSD and NetBSD and POSIX conformance (was "[Bug 194828] [test] lib.libc.sys.getcontext_test.setcontext_link fails on amd64, not i386")

Mehmet Erol Sanliturk m.e.sanliturk at
Fri Dec 19 15:54:56 UTC 2014

On Fri, Dec 19, 2014 at 7:29 AM, Julio Merino <jmmv at> wrote:

> On Fri, Nov 14, 2014 at 12:34 PM, Garrett Cooper <yaneurabeya at>
> wrote:
> >
> > On Nov 14, 2014, at 2:28, Justin Cormack <justin at>
> wrote:
> >
> >> On Fri, Nov 14, 2014 at 7:35 AM,  <bugzilla-noreply at> wrote:
> >>>
> >>>
> >>> --- Comment #12 from Garrett Cooper,425-314-3911 <ngie at>
> ---
> >>> In a perfect world I would like for everything to be consistent
> between FreeBSD
> >>> and NetBSD, but that's not the way it should be, and that's a silly
> ideal to
> >>> hope for :).
> >>
> >> NetBSD dev here... I would rather that tests actually test behaviour
> >> as defined in standards, especially for eg libc tests, and indeed I
> >> have bunch of stuff to add more tests on standards compliance.  So if
> >> stuff is testing implementation internals it should go away, and if
> >> NetBSDs behaviour is incorrect please file an issue, or if the test
> >> setup is not eg standards compliant please file an issue
> >>
> That's a nice ideal... but in practice, the standard does sometimes
> leave details up to the implementation and/or the implementation
> provides custom extensions. Both need tests, and such tests will be
> implementation-dependent.
> So how could we deal with this? Tests for the standard should really
> be unified across both codebases, but there should be a way to
> supplement them with implementation-specific tests. Not sure what the
> best organization scheme for this would be, nor how we'd maintain the
> "common code".

Establish a  "BSD Operating Systems Foundation" and generate a Version
Control System
to be shared among participating establishments such as DragonFly BSD ,
FreeBSD , NetBSD , OpenBSD , and if there are others .

Each participating establishment will maintain its own special parts and
will pull common parts from the common Version Control System.

The common Version Control System will be maintained by groups with
committers from participating establishments .

In that way , common parts will not be maintained separately . This will
reduce costs , waste on human power by unnecessary repeated works , and
therefore will improve common quality .

Decisions will be made by voting and accepting the result . Since ,
participating establishments will continue to work on their operating
systems , if any one wants to apply any different ideas , they may apply
them onto their branches .

My opinion is that , the persons in all of the BSD operating systems groups
are very good human beings and only they need a common cooperation decision
between themselves and work toward realization of it . It is not necessary
to see specialization as a negative effect but a realization of alternative
approaches . Over time , if any such specialization proves to be a more
advantageous approach , it may be adopted by other groups .

Thank you very much .

Mehmet Erol Sanliturk

More information about the freebsd-testing mailing list