Good news everyone,
the Linux Test Project test suite stable release for *August 2014* has
been released.
Since the last release 311 patches by 24 authors were merged.
Notable changes are:
* New testcases and improved coverage for: madvise, waitid, timerfd_*,
getcwd, sched_setaffinity,
Good news everyone,
the Linux Test Project test suite stable release for *August 2014* has
been released.
Since the last release 311 patches by 24 authors were merged.
Notable changes are:
* New testcases and improved coverage for: madvise, waitid, timerfd_*,
getcwd, sched_setaffinity,
Hi!
> >> How much LTP harness type code needs to be used?
> >
> >Not much.
> >
> >For this complexity of tests you would just need to call the tst_resm()
> >interface to report success/failure and, at the end of the test,
> >tst_exit() to return the stored overall test status.
> >
> >And ideally
Hi!
How much LTP harness type code needs to be used?
Not much.
For this complexity of tests you would just need to call the tst_resm()
interface to report success/failure and, at the end of the test,
tst_exit() to return the stored overall test status.
And ideally call the standard
Hi!
> >> I've used LTP in the past (quite a bit), and I felt there was some
> >> advantage to keeping futextest independent.
> >
> >What advantages did you have in mind?
>
> Not CVS was a big one at the time ;-)
>
> OK, I don't mean to be disparaging here... But since you asked, back in
> '09
Hi!
> > That is not the main concern here. If I extract the code I would have to
> > watch for any changes manually. If it was in a library or a separate
> > repository all that would be needed is to add it as dependency/git
> > submodule and I would get all updates automatically.
> >
>
> Yes,
Hi!
> I've used LTP in the past (quite a bit), and I felt there was some
> advantage to keeping futextest independent.
What advantages did you have in mind?
> Perhaps things have changed enough since then (~2009 era) that we
> should reconsider.
I've been working on LTP for a about three years
Hi!
> >> I really believe the proper fix is to use assembly syscall stubs. In
> >> klibc I build a fairly elaborate machinery to autogenerate such syscall
> >> stubs for a variety of architectures.
> >
> > Then it would be nice to share these between klibc and LTP (and possible
> > everybody
Hi!
> > Have a look at this commit that tries to deal with passing 64 bit
> > numbers to syscalls. On 32 bit ABI (but not on X32) these needs to be
> > split up (accordingly to machine endianity).
> >
> > https://github.com/linux-test-project/ltp/commit/04afb02b4280a20c262054e8f99a3fad4ad54916
>
Hi!
> People have a number of times noted that there are problems
> with syscall(), but I'm not knowledgeable on the details.
> I'd happily take a patch to the man page (which, for historical
> reasons, is actually syscall(2)) that explains the the problems
> (and ideally notes those platforms
Hi!
> > However, unless I'm sorely mistaken, the larger problem is that glibc
> > removed the futex() call entirely, so these man pages don't describe
> > something users even have access to anymore. I had to revert to calling
> > the syscalls directly in the futextest test suite because of this:
Hi!
>
> However, unless I'm sorely mistaken, the larger problem is that glibc
> removed the futex() call entirely, so these man pages don't describe
> something users even have access to anymore. I had to revert to calling
> the syscalls directly in the futextest test suite because of this:
>
>
Hi!
However, unless I'm sorely mistaken, the larger problem is that glibc
removed the futex() call entirely, so these man pages don't describe
something users even have access to anymore. I had to revert to calling
the syscalls directly in the futextest test suite because of this:
Hi!
However, unless I'm sorely mistaken, the larger problem is that glibc
removed the futex() call entirely, so these man pages don't describe
something users even have access to anymore. I had to revert to calling
the syscalls directly in the futextest test suite because of this:
Hi!
People have a number of times noted that there are problems
with syscall(), but I'm not knowledgeable on the details.
I'd happily take a patch to the man page (which, for historical
reasons, is actually syscall(2)) that explains the the problems
(and ideally notes those platforms where
Hi!
Have a look at this commit that tries to deal with passing 64 bit
numbers to syscalls. On 32 bit ABI (but not on X32) these needs to be
split up (accordingly to machine endianity).
https://github.com/linux-test-project/ltp/commit/04afb02b4280a20c262054e8f99a3fad4ad54916
That
Hi!
I really believe the proper fix is to use assembly syscall stubs. In
klibc I build a fairly elaborate machinery to autogenerate such syscall
stubs for a variety of architectures.
Then it would be nice to share these between klibc and LTP (and possible
everybody else).
It
Hi!
I've used LTP in the past (quite a bit), and I felt there was some
advantage to keeping futextest independent.
What advantages did you have in mind?
Perhaps things have changed enough since then (~2009 era) that we
should reconsider.
I've been working on LTP for a about three years now
Hi!
That is not the main concern here. If I extract the code I would have to
watch for any changes manually. If it was in a library or a separate
repository all that would be needed is to add it as dependency/git
submodule and I would get all updates automatically.
Yes, and for that
Hi!
I've used LTP in the past (quite a bit), and I felt there was some
advantage to keeping futextest independent.
What advantages did you have in mind?
Not CVS was a big one at the time ;-)
OK, I don't mean to be disparaging here... But since you asked, back in
'09 LTP had some test
Good news everyone,
The Linux Test Project test suite stable release for *April 2014* has
been released.
Since the last release 210 patches by 27 authors were merged.
Notable changes are:
* Continued effort to cleanup old testcases
(about 30 testcases were cleaned up/rewritten)
* 20 new
Good news everyone,
The Linux Test Project test suite stable release for *April 2014* has
been released.
Since the last release 210 patches by 27 authors were merged.
Notable changes are:
* Continued effort to cleanup old testcases
(about 30 testcases were cleaned up/rewritten)
* 20 new
Hi!
> > and there's no good
> > reason to believe that this behavior would have persisted
> > indefinitely.
> >
> > The msync(2) man page (as currently written in man-pages.git) is
> > silent on the behavior if both flags are unset, so this change should
> > not break an application written by
Hi!
and there's no good
reason to believe that this behavior would have persisted
indefinitely.
The msync(2) man page (as currently written in man-pages.git) is
silent on the behavior if both flags are unset, so this change should
not break an application written by somone who
Hi!
> > +static unsigned long count_vma_pages_range(struct mm_struct *mm,
> > + unsigned long addr, unsigned long end)
> > +{
> > + unsigned long nr_pages = 0;
> > + struct vm_area_struct *vma;
> > +
> > + /* Find first overlaping mapping */
> > + vma = find_vma_intersection(mm,
Hi!
+static unsigned long count_vma_pages_range(struct mm_struct *mm,
+ unsigned long addr, unsigned long end)
+{
+ unsigned long nr_pages = 0;
+ struct vm_area_struct *vma;
+
+ /* Find first overlaping mapping */
+ vma = find_vma_intersection(mm, addr, end);
+
Hi!
> I've seen the LTP open posix mmap/{11-4,11-5} issues in the past myself
> and was something I wanted to discuss on the lists myself. Thanks for
> bringing this up.
>
> Jut to reiterate: the expectations are
>
> 1. zero filling of unmapped (trailing) partial page
> 2. NO Writeout (to disk)
Hi!
I've seen the LTP open posix mmap/{11-4,11-5} issues in the past myself
and was something I wanted to discuss on the lists myself. Thanks for
bringing this up.
Jut to reiterate: the expectations are
1. zero filling of unmapped (trailing) partial page
2. NO Writeout (to disk) of
Hi!
> > Strictly speaking this is not a bug at least when sticking to regular
> > files as POSIX which says that the change is not written out. In this
> > case the file content is correct and forcing the data to be written out
> > by msync() makes the test pass. The SHM mappings seems to preserve
Hi!
Strictly speaking this is not a bug at least when sticking to regular
files as POSIX which says that the change is not written out. In this
case the file content is correct and forcing the data to be written out
by msync() makes the test pass. The SHM mappings seems to preserve the
Hi!
I'm currently revisiting mmap related tests in LTP (Linux Test Project)
and I've came to the tests testing that writes to the partially
mapped page (at the end of mapping) are carried out correctly.
These tests fails because even after the object is unmapped and the
file-descriptor closed the
Hi!
I'm currently revisiting mmap related tests in LTP (Linux Test Project)
and I've came to the tests testing that writes to the partially
mapped page (at the end of mapping) are carried out correctly.
These tests fails because even after the object is unmapped and the
file-descriptor closed the
32 matches
Mail list logo
