Open POSIX Test Suite

You are about to duplicate http://ltp.sf.net

I imagine the main difference is you're targeting Posix compliance rather than LSB compliance. That seems like a fairly minor difference that could be accommodated within the framework of the LTP.

Or do you feel the existing test framework and tests assembled in LTP are so inadequate that you need to start an entirely new project doing essentially the same thing?

(Apologies if you've already answered this question. I did check your web page, but didn't see an answer.)
- Dan

My understanding is that LTP is focused on current mainline kernel testing, while this project's initial concern is areas that are not currently in Linux like POSIX message queues, semaphores, and full support for POSIX threads. I see this as being used to evaluate different implementations that are being considered for inclusion in the kernel, glibc, etc.

This project is concerned with the POSIX APIs regardless of where they are implemented (kernel, glibc, etc.). Thus it can focus on POSIX, independent of implementation. This project will be more concerned with traceability back to the POSIX specification, and completeness of coverage, than I would expect from LTP.

That said, there is some overlap, and an exchange of test cases between the projects may be very useful.

I've copied Stephanie from LTP to get her reaction.

-- Geoff Gustafson

These are my views and not necessarily those of my employer.

Geoff,
thanks for the reply. I have a feeling that LTP would be overjoyed to have you contribute to the LTP and make it a more accurate Posix compliance test. The areas that Linux does not currently cover -- message queues, semaphores, etc -- *should* be in the LTP, regardless of whether Linux currently implements them. Linux's 'expected results' on these tests would be 'fail' at the moment. That's not a problem.

The LTP would also greatly benefit from better tracability and coverage.

I urge you to consider ways in which you could work within the framework of the LTP to meet both your goals and the LTP's goals. They may be more in synch than you originally thought!
- Dan

[ .. snip .. ]

You are correct. LTP isn't trying to be any kind of "compliance" test. We're just trying to exercise and stress the Linux kernel to find bugs and guard against regressions.

I don't think LTP's "framework[1]" is going to help Geoff complete his project. Geoff already created a SourceForge site. As part of the LTP, I probably would have given him a separate CVS module and a mailing list. I think he has everything he needs to get started already.

That being said, if Geoff does want his Open POSIX test suite to be part of the LTP, we'll gladly accomodate him.

[1] By framework I think you mean logistical, not libraries. I think our test libraries have some things he might like. I just recommend cleaning them up before using them.

Nate Straz                                              [email protected]
sgi, inc                                           http://www.sgi.com/
Linux Test Project                                  http://ltp.sf.net/

Anyone know what the relationship between the LTP and LSB Posix compliance tests are? Were they both originally derived from the OpenGroup Posix compliance tests?
- Dan

The emphasis on what the test suites are trying to achieve does differ
- eg the LSB doesn't have endurance type tests and concentrates more on writing tests which can be used for certification purposes. And of course the LSB test suites only cover the areas that the LSB spec requires.

I don't think the LTP were tests derived from the OpenGroup (though I'm not that familiar with them).

Chris

[email protected]
IBM OzLabs Linux Development Group
Canberra, Australia