Quoting Garrett Cooper ([email protected]):
> On Tue, Mar 2, 2010 at 9:56 PM, Rishikesh K Rajak
> <[email protected]> wrote:
> > On Tue, Mar 02, 2010 at 10:25:23AM -0800, Garrett Cooper wrote:
> >> On Mar 2, 2010, at 9:35 AM, "Serge E. Hallyn" <[email protected]> wrote:
> >>
> >> > Quoting Garrett Cooper ([email protected]):
> >> >>
> >> >> That would be from me; I do that via autoconf and they probably
> >> >> fubared the headers on Redhat or something... Do you have
> >> >
> >> > Oh, ok. Well I suspect we can ditch the check_simple_capset.c
> >> > altogether if autoconf is (eventually :) doing the detection for
> >> > us. The only point of check_simple_capset.c was to check whether
> >> > libcap is there and whether we should run the real tests.
> >> >
> >> >> libcap-devel installed?
> >> >
> >> > yup:
> >> >
> >> > [r...@oracer4b ltp-dev]# rpm -qa|grep libcap
> >> > libcap-2.10-2.fc10.x86_64
> >> > libcap-devel-2.10-2.fc10.x86_64
> >> >
> >> > [r...@oracer4b ltp-dev]# grep CAP_LIB *
> >> > config.log:CAP_LIBS=''
> >> > config.status:S["CAP_LIBS"]=""
> >> > configure:CAP_LIBS'
> >> > configure: CAP_LIBS="-lcap"
> >> >
> >> > so somehow -lcap was not detected by configure?
> >>
> >> Well some of the definitions are there but maybe not all of them.
> >> config.log would help...
> >>
> >
> > Here is the config.log snapshot, it seems it has some error:
> >
> > ...
> > configure:5543: checking whether CAP_BSET_DROP is declared
> > configure:5574: gcc -c -g -O2 conftest.c >&5
> > conftest.c: In function 'main':
> > conftest.c:38: error: 'CAP_BSET_DROP' undeclared (first use in this
> > function)
> > conftest.c:38: error: (Each undeclared identifier is reported only once
> > conftest.c:38: error: for each function it appears in.)
>
> Yes -- and I think this is because the constants no longer have
> the same name:
>
> http://fxr.watson.org/fxr/source/include/linux/prctl.h?v=linux-2.6#L68
>
> Note -- CAP_BSET_DROP should be: PR_CAPBSET_DROP, etc.
>
> Which is why I stress _not_ putting these hardcoded constants in
> test files (POLLHDRDUP -- or whatever it was in ppoll01 -- is the only
1. this was (almost certainly) a typo on my part
2. not using these constants, like PR_CAPBSET_READ, when testing
prctl(PR_CAPBSET_READ)? I think I must be misunderstanding what
you are suggesting
3. this type of thing almost inevitably results from the desire to
enable ltp to test features early. When features hit -mm for instance,
it is possible for names and such to still change before hitting
upstream. For an extreme example look at
git whatchanged -p include/linux/securebits.h
in the kernel - those features had been there for years, but didn't
get their publically exported names until late last year. I have
been wanting to send ltp testcases for those for years (and have
some sitting around for as long), but the naming problem is exactly
what caused my latest delay.
One day I need to finish those up, bc it's a subtle, rarely-used
and never-tested spot in the kernel code right now. Guess I was
waiting to see when /usr/include/sys/securebits.h magically shows up
in a fedora or ubuntu system.
> real violation I can remember OTOH that I need to clean up
> eventually). We need to be consistent with any and all documentation
> provided to end-developers or we [LTP] are going to shoot ourselves in
> the foot if and when the underlying functionality changes.
> I'll update the tests this weekend, but I would like it if someone
> test the tests on an outdated distro (RHEL 4.x?) once I provide a
I can find/build a RHEL5 box to test on
> patch to ensure that nothing's being regressed. Based on some really
> simple inspection it appears that these tests are compatible only with
> libcapability 2.x+, but I could be wrong...
jinkeys - yes, libcap 1 had its last update in august 2007, and I don't
think it supports 64-bit capabilities.
Note that cap_bound also has a dud 'check_for_libcap.sh' file which
your autoconf magic <waves hands around mysteriously> should be able
to better replace. There is something that could stand to be in ltp
git tree - a little 1-page tutorial for properly adding (1) kernel
feature and (2) library tests to control compilation and running of
ltp tests to autoconf.
> Thanks,
> -Garrett
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
