[Skyeye-developer] Development plan for SkyEye-1.2.5 in draft

[Joel Sherrill]

Yu Chen wrote:
> Kang and I discussed before, and we think 1~3 should be implemented
> first, because these parts are independent from the concrete
> processors and is useful to add more debug/test/profile functions on
> SkyEye.
>
>   
I'm not arguing about the importance.  Just that some of the
test suites we regularly run include > 2000 executable tests
which when successful exit cleanly after just seconds of
CPU time.  We need a way for the simulated program to
make the simulator exit.  So improving testing capabilities
for simulated improvements includes some things that make
automated testing more efficient.
> BTW,
> Now my students and I are developing a small rtems for pc386 using cmake.
> I think cmake maybe is better than autotools.
> KDE4 is good example.
>   
What do you mean by small?  The code on the CVS head
continues to shrink.

I don't know that much about cmake but we have a lot invested
in autotools so it is highly unlikely we will switch unless
the GNU standards themselves change.  That would likely
take Moses bring the next Ten Commandments down. :-D

--joel
>
> 2007/12/3, Joel Sherrill <joel.sherrill at oarcorp.com>:
>   
>> Michael.Kang wrote:
>>     
>>> After some collection of requirement from some users, I have the
>>> following feature list for our next version of SkyEye in my mind:
>>> 1. Add autoconf/automake support to deal with some compilation issues
>>> and portability in different platforms.
>>> 2. Add a unique memory read/wirte interface for all the arch and the devices.
>>> 3. Add code coverage profiling function in SkyEye to support OS testing
>>> 4. Improve au1100 simulation , make linux and RTEMS BSP run on SkyEye.
>>> 5. (optional)  Simulate lemote processor and make lemote BSP of linux
>>> run on SkyEye.
>>> 6.(optional)  Implement PCI interface ,run some simple PCI peripherals
>>> such as PCI uart.
>>> 7 (optional) Implement ARMv6 support and simulates integrator machine.
>>>
>>>       
>> I appreciate the (2) and (3) items. :)
>>
>> I would like to add a couple of more items that would help
>> RTEMS automated tested.
>>
>> + some way for the program being run to make Skyeye exit.
>>     On other simulators we use, there may be a system call
>>     or magic address to write to.   I would be happy with a
>>     "shutdown device" which can be mapped into any target's
>>     address space at any address.  When you write to it, the
>>    simulator exits.
>>
>>    I ask for the "shutdown device" because most RTEMS tests
>>    run < 35 seconds of simulated time and exit cleanly.  This is
>>    also the situation for tests from GCC.  If we compiled with
>>    optional BSP support for the simulator's shutdown device,
>>    this would speed testing.
>>
>> + A command line limit on simulated CPU time executed.
>>    I didn't check if this was present but it is also useful to
>>    prevent hanging tests from running for hours.
>>
>> + A review of the RTEMS Wiki Skyeye page to see if it is up to
>>    date and any other configuration makes sense to try.
>>   http://www.rtems.org/wiki/index.php/SkyEye
>>
>> I want to thank the Skyeye community for their support.  It
>> has really been nice to see more RTEMS BSPs testable on
>> Skyeye.  It is really an aid to us.
>>
>> --joel
>>     
>>> If any guys have more ideas, you are welcome to add more and discuss
>>> them. If like to take part in some development of the above feature,
>>> you can send email to me.
>>>
>>> -- Thanks
>>> -- Michael.Kang
>>>
>>>
>>>       
>> _______________________________________________
>> CLinux.org Websites:
>> http://seohelper.cn/
>> http://www.implight.net/
>> http://gro.clinux.org/
>> Skyeye-developer mailing list
>> Skyeye-developer at lists.gro.clinux.org
>> http://lists.gro.clinux.org/cgi-bin/mailman/listinfo/skyeye-developer
>>
>>     
>
>
>