[VirtLayer] Midterm patches and blog update

Joel Sherrill joel.sherrill at OARcorp.com
Mon Aug 19 19:34:59 UTC 2013


On 8/19/2013 1:48 PM, Gedare Bloom wrote:
> I think you can use the rtems-testing.git module with the pc386 script
> to run the tmtests in non-interactive mode. Then you just need to run
> all of them (easy to script), and it should dump the output to the
> "log/" subdirectory. I think there are instructions on our wiki page
> about Qemu... ask if you don't figure it out easily. :)
Yep. That's about it.

pc386 *.exe

or even "pc386 `find . -name "*.exe"` from the top
of the build tree.

Replace pc386 with any BSP which has a simulator run script
that's supported and it operates the same.
> -Gedare
>
> On Mon, Aug 19, 2013 at 12:34 PM, Philipp Eppelt
> <philipp.eppelt at mailbox.tu-dresden.de> wrote:
>> Is there an automatic way to do all tmtests on qemu?
>>
>> The score-libcpu_native patch is ready. I just need to do the tests.
>>
>>
>> On 08/15/2013 06:25 PM, Joel Sherrill wrote:
>>> My experience in the past is that it is accurate enough to see changes. It is more about the relative change that precise numbers.
>>>
>>> Gedare Bloom <gedare at rtems.org> wrote:
>>>
>>>
>>> You ought to test the patch that moves code from score to libcpu with
>>> the tmtests to ensure that none of the timing changes. (Hm, does
>>> pc386/qemu offer accurate tmtest timing results?)
>>>
>>> -Gedare
>>>
>>> On Wed, Aug 14, 2013 at 1:36 PM, Gedare Bloom <gedare at rtems.org> wrote:
>>>> Please merge the part of the libcpu_i386_midterm.patch that contains
>>>> the relocated code into the score_i386_midterm.patch since the score
>>>> patch will not work right without reimplementing the libcpu part. Make
>>>> the addition of the virtual subdirectory of the libcpu a separate
>>>> patch that includes everything needed for it to work, probably by
>>>> merging it with the virtPok BSP.
>>>>
>>>> Please try to submit the patches directly to the mailing list with
>>>> git-send-email, it is easier to review patches that are emailed
>>>> directly instead of attached. Instructions can be found on the RTEMS
>>>> wiki Git_Users page.
>>>>
>>>> Other notes:
>>>> * avoid two or more blank lines in a row
>>>> * break lines longer than 80 characters
>>>> * don't use "Intel" to specify the i386 type in comments (other x86
>>>> brands should work..)
>>>> * put the extern "C" after include files. "C" files should not need
>>>> it, only header files.
>>>> * Delete "Formerly contained in and extracted from libcpu/i386/cpu.h"
>>>> from interrupts.h header comment. Possibly add comment "Relocated from
>>>> score/cpu/i386"
>>>> * rename files to avoid humpBackNotation. Files in RTEMS are usually
>>>> alllowercase so let us follow the usual way.
>>>> * Remove "Date: XX/YY/ZZZZ" from file comments
>>>> * Replace "Author: Philipp Eppelt" with a copyright statement e.g.
>>>> "Copyright (c) 2013 Philipp Eppelt."
>>>> * "virt_disableInterrupts" and "virt_enableInterrupts" are undefined.
>>>> Also they should be given a proper RTEMS name, e.g.
>>>> _CPU_Virtual_Disable_interrupts() or something.
>>>> * Add your copyright to the virtual/include/rtems/score/interrupts.h.
>>>> You substantially transformed this code and should lay claim to your
>>>> copyright.
>>>>
>>>> -Gedare
>>>>
>>>> On Wed, Jul 31, 2013 at 4:17 PM, Philipp Eppelt
>>>> <philipp.eppelt at mailbox.tu-dresden.de> wrote:
>>>>> Patch for libcpu, introducing CPU models 'native' and 'virtual' and
>>>>> implementing functions removed from score.
>>>>>
>>>>> _______________________________________________
>>>>> rtems-devel mailing list
>>>>> rtems-devel at rtems.org
>>>>> http://www.rtems.org/mailman/listinfo/rtems-devel
>>>>>
>>> _______________________________________________
>>> rtems-devel mailing list
>>> rtems-devel at rtems.org
>>> http://www.rtems.org/mailman/listinfo/rtems-devel
>>>


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985




More information about the devel mailing list