From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15459 invoked by alias); 2 Jul 2011 09:14:53 -0000 Received: (qmail 15451 invoked by uid 22791); 2 Jul 2011 09:14:53 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 02 Jul 2011 09:14:39 +0000 Received: by mail.ecoscentric.com (Postfix, from userid 48) id D67572F78003; Sat, 2 Jul 2011 10:14:37 +0100 (BST) From: bugzilla-daemon@bugs.ecos.sourceware.org To: unassigned@bugs.ecos.sourceware.org Subject: [Bug 1001253] Kernel tests on small memory targets X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: Other X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: sergei.gavrikov@gmail.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: In-Reply-To: References: X-Bugzilla-URL: http://bugs.ecos.sourceware.org/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Sat, 02 Jul 2011 09:14:00 -0000 Message-Id: <20110702091435.BEDB22F7800E@mail.ecoscentric.com> Mailing-List: contact ecos-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-bugs-owner@sourceware.org X-SW-Source: 2011/txt/msg00984.txt.bz2 Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001253 --- Comment #10 from Sergei Gavrikov 2011-07-02 10:14:31 BST --- Hi Ilija, First, thank you for your tests. But, I have a doubt about your workaround. What will happen if someone will try to manage the kernel tests for 16K or 48K targets? Of course, it would be great if those predefined values (NTHREADS, PHILOSOPHERS, etc.) were CDLized, but, in such a case a user must have an expert knowledges in eCos kernel internals to manage predefined values in eCos configtool, otherwise, I afraid we will get more reports from newbies that kernel tests do hang during its runs. Well, it is my view only. I think that it would be better to have a way to manage a set of the kernel tests, but, unfortunately, CDL CYGPKG_KERNEL_TESTS option is *calculated* thing. I think that we would s/calculated/default_value/ for it and then low memory footprint targets will get a way to reduce the set of the kernel tests. I mean cdl_option CYGPKG_KERNEL_TESTS { display "Kernel tests" flavor data no_define # s/calculated/default_value/ default_value { ... } } and on the target's side (target.cdl) to have something like # This option would be a component with a set of the same # per-package options cdl_option CYGBLD_TARGET_TESTS_QUARANTINE { active_if CYGPKG_KERNEL default_value 1 requires { !is_substr(CYGPKG_KERNEL_TESTS, " tests/tm_basic") } ... requires { !is_substr(CYGPKG_KERNEL_TESTS, " tests/fptest") } } Well, perhaps, I'm totally wrong here. Really, it's cool to run 'tm_basic' test on 32K targets, but, I would not want to see another set of predefined limits (your 32K-limits) in the test's sources. It seems for me we need in more elegant way to manage the issue if that is possible at all. Sergei -- Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.