On Tue, 03 Mar 2009 10:28:07 +0100, Michal Simek
<[email protected]> wrote:
> Hi Jiri,
>
>>>>> I think that is the right time to start with arch dependent
>>>>> compilation.
>>>>> Here is the patch which solve my problem with hyperthreading
>>>>> compilation.
>>>>>
>>>>> Mike: Any comments? If not I'll prepare proper patch for Subrata.
>>>>>
>>>>> --- a/Makefile
>>>>> +++ b/Makefile
>>>>> +ifndef ARCH
>>>>> +ARCH=i386
>>>>> +endif
>>>>>
>>>>
>>>> this is no good imo. the ARCH should either be discovered
>>>> automatically, or
>>>> not at all.
>>>>
>>> Arch should be discover automatically for systems where you compile LTP
>>> but not when you cross compile on x86 for different arch.
>>
>> In that case, "not at all" applies. Also, the change you've posted
>> raises several questions
>>
>> - why do you add a macro ARCH, that is generally not used in the LTP?
> I think that it the right time to start with ARCH depended compilation
> -> I mean as target arch.
>> - why resort to 386, and not x86-64, sparc or powerpc
> From my point of view is the question not important for me. I do
> Microblaze and I believe that in the main Makefile Microblaze won't be
> as default arch.
> This is question on x86 guys.
>
>>
>> Also, the compiler really should set architecture spcific macros based
>> on the target.
> I don't know full LTP history but I think that is primary focus on x86
> where is target the same arch where is LTP compiled.
Certainly not. Only RedHat-originated patches are i386+x86-64 only :)
> I believe that people tried to compile LTP on x86 for another arch.
> That's my case and I just trying to solve build problems which I have.
Yes, but why would you make such invasive changes to the build & test run
system, for such a petty error? BTW the HT tests are integrated since
december, which is not that long.
> I can fix easily fix it in my private tree but I think that this help me
> or microblaze community but in general the problem will be there. I
> don't want to
> manage patches and take care about them. That's why I would like to
> solve it directly in LTP. And this discuss is only about how to do it in
> right way.
>
>>
>>>>
>>>>> --- a/testcases/kernel/sched/Makefile
>>>>> +++ b/testcases/kernel/sched/Makefile
>>>>> +ifeq ($(ARCH),i386)
>>>>> +SUBDIRS += hyperthreading
>>>>> +endif
>>>>>
>>>>
>>>> i thought the code already had #ifdef's in it you could fix up easily
>>>> ?
>>>> -mike
>>>>
>>> Some ifdefs are there but the question is why we should compile tests
>>> which we don't need for non x86 arch.
>>
>> ... and the answer is yes, and the rationale is that we want that the
>> tests not fail on non x86 architectures, and for this, we need the
>> files to be there.
> I understand that some fake tests are good for finding bugs on another
> arch but these feature don't break any compilation for all arch but not
> tests which only write answer that this test cannot be run on this arch.
>>
>>> Ifdef which are there are only for i[3-6]86. This covered only cases
>>> when you compile ltp on powerpc for powerpc test - that's work.
>>> Adding more ifdef to code seems to me useless.
>>
>> Why would you need to add ifdefs? Does a simple s/ARCH_i386/__i386__/g
>> not work for you?
> I believe that this can work but there is still question why and I have
> no problem to have it there but...
> Please look at testcases/kernel/hyperthreading/ht_affinity/HTaffinity.c
> to lines 229-235.
> There is part of code for different arch -> Maybe I am missing something
> but I can't realize what can bring me this test.
This will bring you a non-failure on other achitectures when you run the
tests with pan. Because we have no architecture-dependent execution and no
means to determine if a test was not run because it's missing due to
error in the Makefile etc. or because it's not for this architecture,
other than making a stub test and returning TCONF which is not a failure.
One may think "who cares?", but people do, because automatic test result
reporting tools like it that way.
> I see there -> wasting compilation time, wasting space on rootfs, log,
> website, wasting time for checking which test failed.
Since it can't fail on non-i386, this is not a big deal. Moreover, there
are fast ways to determined what failed.
> I hear you that you think that everywhere is a lot of space and
> compilation time is no problem on current machine but every wasting is
> wrong.
First, don't hear that I think what I don't say. Second, if you want to
save substantial amount of disk space, you can try making libltp a dynamic
library. This should save several megabytes in the testcases/bin directory.
Regards
Jiri Palecek
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
