posix compliance test

[Christos Zoulas]

Hi,

I am trying to get the posix compliance tests from:

http://sourceforge.net/projects/posixtest/?source=directory

running, but a lot of stuff does not compile because we are missing
some API's. The code does a good job to find what is supported by
using sysconf(), for example it checks _SC_THREAD_PROCESS_SHARED
before calling pthread_condattr_setpshared(), but unfortunately we
don't supply the function at all (instead of supplying it and
returning EOPNOTSUPP/EINVAL).

I think that supplying the function and returning an error is better and
will let the tests work without causing excessive ifdefing of the sources.

Does anyone have any other/better ideas?

christos

[Matt Thomas]

Post by Christos Zoulas
Hi,
http://sourceforge.net/projects/posixtest/?source=directory
running, but a lot of stuff does not compile because we are missing
some API's. The code does a good job to find what is supported by
using sysconf(), for example it checks _SC_THREAD_PROCESS_SHARED
before calling pthread_condattr_setpshared(), but unfortunately we
don't supply the function at all (instead of supplying it and
returning EOPNOTSUPP/EINVAL).
I think that supplying the function and returning an error is better and
will let the tests work without causing excessive ifdefing of the sources.
Does anyone have any other/better ideas?

I've had a local fix which has done that for years. :)

[Christos Zoulas]

On Dec 9, 1:55pm, ***@3am-software.com (Matt Thomas) wrote:
-- Subject: Re: posix compliance test

| > I am trying to get the posix compliance tests from:
| >
| > http://sourceforge.net/projects/posixtest/?source=directory
| >
| > running, but a lot of stuff does not compile because we are missing
| > some API's. The code does a good job to find what is supported by
| > using sysconf(), for example it checks _SC_THREAD_PROCESS_SHARED
| > before calling pthread_condattr_setpshared(), but unfortunately we
| > don't supply the function at all (instead of supplying it and
| > returning EOPNOTSUPP/EINVAL).
| >
| > I think that supplying the function and returning an error is better and
| > will let the tests work without causing excessive ifdefing of the sources.
| >
| > Does anyone have any other/better ideas?
|
| I've had a local fix which has done that for years. :)

Can you commit what you have so I don't end up re-doing it? There is not
that function only but a bunch of them.

christos

[Joerg Sonnenberger]

Post by Christos Zoulas
I think that supplying the function and returning an error is better and
will let the tests work without causing excessive ifdefing of the sources.

I don't agree with this completely. Process-shared mutexes are
fundamentally not supported by our lwp_park/lwp_unpark interface without
jumping through a lot of hops. Failing the enable call therefore is
huge semantic change and checking for a working function a much harder
requirement than checking for the presence of a function.

Joerg

[Christos Zoulas]

Post by Joerg Sonnenberger

Post by Christos Zoulas
I think that supplying the function and returning an error is better and
will let the tests work without causing excessive ifdefing of the sources.

I don't agree with this completely. Process-shared mutexes are
fundamentally not supported by our lwp_park/lwp_unpark interface without
jumping through a lot of hops. Failing the enable call therefore is
huge semantic change and checking for a working function a much harder
requirement than checking for the presence of a function.

We could require a #define __NetBSD_unimplemented__ to be defined to
make them header visible. But they would still be library visible. Is
that ok?

christos

[Thomas Klausner]

Post by Christos Zoulas
We could require a #define __NetBSD_unimplemented__ to be defined to
make them header visible. But they would still be library visible. Is
that ok?

The way configure scripts are written in general, I don't think that's
a good idea. When configure scripts find functions, they expect them
to be useful.

Why do we need to fake unavailable functions at all?
Thomas

[Christos Zoulas]

Post by Thomas Klausner

Post by Christos Zoulas
We could require a #define __NetBSD_unimplemented__ to be defined to
make them header visible. But they would still be library visible. Is
that ok?

The way configure scripts are written in general, I don't think that's
a good idea. When configure scripts find functions, they expect them
to be useful.
Why do we need to fake unavailable functions at all?

As I mentioned in the beginning of the thread compliance tests find features
using sysconf() not configure tests. They expect the functions to be there,
and they just test them. Without the function presense we cannot even run
the compliance tests.

christo

[Thomas Klausner]

Post by Christos Zoulas
As I mentioned in the beginning of the thread compliance tests find features
using sysconf() not configure tests. They expect the functions to be there,
and they just test them. Without the function presense we cannot even run
the compliance tests.

IMHO the compliance tests need fixing :)
Thomas

[Christos Zoulas]

On Dec 10, 3:08pm, ***@NetBSD.org (Thomas Klausner) wrote:
-- Subject: Re: posix compliance test

| On Tue, Dec 10, 2013 at 02:02:40PM +0000, Christos Zoulas wrote:
| > As I mentioned in the beginning of the thread compliance tests find features
| > using sysconf() not configure tests. They expect the functions to be there,
| > and they just test them. Without the function presense we cannot even run
| > the compliance tests.
|
| IMHO the compliance tests need fixing :)

Let me know when you've fixed them, so I can start testing.

christos

[David Brownlee]

Post by Christos Zoulas

Post by Thomas Klausner

Post by Christos Zoulas
We could require a #define __NetBSD_unimplemented__ to be defined to
make them header visible. But they would still be library visible. Is
that ok?

The way configure scripts are written in general, I don't think that's
a good idea. When configure scripts find functions, they expect them
to be useful.
Why do we need to fake unavailable functions at all?

As I mentioned in the beginning of the thread compliance tests find features
using sysconf() not configure tests. They expect the functions to be there,
and they just test them. Without the function presense we cannot even run
the compliance tests.

How about putting all the EOPNOTSUPP/EINVAL stubs into a single .c
which is just built along with the compliance tests?

[Christos Zoulas]

You need the header info to compile (constants etc)

christos

[John Nemeth]

On Dec 10, 2:02pm, Christos Zoulas wrote:
} In article <***@danbala.tuwien.ac.at>,
} Thomas Klausner <***@NetBSD.org> wrote:
} >On Tue, Dec 10, 2013 at 12:17:50AM +0000, Christos Zoulas wrote:
} >> We could require a #define __NetBSD_unimplemented__ to be defined to
} >> make them header visible. But they would still be library visible. Is
} >> that ok?
} >
} >The way configure scripts are written in general, I don't think that's
} >a good idea. When configure scripts find functions, they expect them
} >to be useful.
} >
} >Why do we need to fake unavailable functions at all?
}
} As I mentioned in the beginning of the thread compliance tests find features
} using sysconf() not configure tests. They expect the functions to be there,
} and they just test them. Without the function presense we cannot even run
} the compliance tests.

If we can't even compile the compliance tests, then it must
be that we're not compliant. :->

}-- End of excerpt from Christos Zoulas

[Steffen "Daode" Nurpmeso]

John Nemeth <***@cue.bc.ca> wrote:
| If we can't even compile the compliance tests, then it must
|be that we're not compliant. :->

You need GNU make.

--steffen

[Mouse]

Post by Steffen "Daode" Nurpmeso

If we can't even compile the compliance tests, then it must be that
we're not compliant. :->

You need GNU make.

If you need tools beyond what POSIX calls for for a POSIX compliance
test suite, I would say the test suite is cripplingly broken. In
particular, if a POSIX-conforming make isn't good enough I have trouble
taking the test suite seriously. (Not that it's my decision, of
course.)

Or is NetBSD's make not POSIX enough? Then I'd say NetBSD needs to fix
that first.

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

[Steffen "Daode" Nurpmeso]

Mouse <***@Rodents-Montreal.ORG> wrote:
|> You need GNU make.
|
|If you need tools beyond what POSIX calls for for a POSIX compliance
|test suite, I would say the test suite is cripplingly broken. In
|particular, if a POSIX-conforming make isn't good enough I have trouble
|taking the test suite seriously. (Not that it's my decision, of
|course.)

My guess was that it was a boring and disillusioning ergotherapy
for a beginners department. It hasn't seen work for many years,
too, when i can trust the web interface. I ran it out of interest
two days ago and got a ~660 KB log, yet am busy with multiple
reported bugs in stuff i maintain.

|Or is NetBSD's make not POSIX enough? Then I'd say NetBSD needs to fix
|that first.

They use pattern syntax, multiple targets with identical names
etc. At least the former seems to become part of the next revised
POSIX, but since i always used most-minimal make(1) syntax to
avoid any problems i am no real expert. At least the Makefile
manages to silently do nothing with NetBSD make. This could of
course and instead also show deep intellectual penetration of
cross-platform make(1) internals. Intel is on top of the hill.

--steffen

[John Nemeth]

On Dec 11, 2:28pm, Mouse wrote:
}
} >> If we can't even compile the compliance tests, then it must be that
} >> we're not compliant. :->
}
} > You need GNU make.
}
} If you need tools beyond what POSIX calls for for a POSIX compliance
} test suite, I would say the test suite is cripplingly broken. In

For those that haven't been following the thread, the real
issue is missing pthread functions. As evidenced by the smiley,
my response was intended to be taken a joke, and not intended to
be taken seriously.

}-- End of excerpt from Mouse

[Martin Husemann]

I would suggest to add the failing stubs Christos suggested, but
#ifdef __BROKEN_STUPID_POSIX_TEST_SUITE
and add a build knob (like: MKSTUPIDPOSIXTESTSUITESTUBS=YES) to activate
them.

Of course leave them out of normal builds, as that would likely break more
other programs.

Those who intend to run this apparently very stupid test suite then can do
so easily with a custom build.


Martin

[Hubert Feyrer]

Post by Martin Husemann
I would suggest to add the failing stubs Christos suggested, but
#ifdef __BROKEN_STUPID_POSIX_TEST_SUITE
and add a build knob (like: MKSTUPIDPOSIXTESTSUITESTUBS=YES) to activate
them.

Is that really worth the trouble?
Better just autoconf the Posix suite on its way to pkgsrc... :)


- Hubert