This is the mail archive of the ecos-bugs@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug 1001253] Kernel tests on small memory targets


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 <sergei.gavrikov@gmail.com> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]