Gsoc 2012 project

[Yang Wei]

发自我的 iPad

在 2012-2-8，7:54，Chris Johns <chrisj at rtems.org> 写道：

> On 8/02/12 1:34 AM, yangwei weiyang wrote:
>> Hi all:
>>     From the mail of Joel I know that the Google summer of code 2012 is
>> going to start and RTEMS will be absolutely a member of organizations.
>> There are lots of projects i am interested in from the Wiki open project
>> section. The most favorite one for me is "Bus Space API". So i want to
>> know as much information as possible.
> 
> Thanks for looking.
> 
>>     First i have read "Bus Space API" section carefully at the Wiki,
>> And also know some basic backgroud through the IRC log. The bus_space
>> API is originally from NetBSD, its goal is to allow a single driver
>> source file to manipulate a set of devices on different system
>> architectures, and to allow a single driver object file to manipulate a
>> set of devices on multiple bus types on a single architecture. It is
>> implemented in the BSP layer and the architecture layer, that  means
>> different architecture and machine must implement its own bus space type
>> and
>> functions. But the goal of "Bus Space API" project is to easing the
>> ports of BSD drivers to RTEMS, so in order to realize its goal, should
>> we port bus_space API to RTEMS BSP layer and architecture layer or adapt
>> the bus_space API in the RTEMS score which make BSP layer and
>> architecture layer unchanged or changed minimum?
>>     So i want to know more information about this project, are there
>> some protential mentors to help me?
>> 
> 
> The bus space project is complex and I suspect beyond the scope of GSoC from past experience. The issue is the way it needs to be embedded into the score and the RTEMS name-space then mapped to the BSD API with a low overhead.
> 
This project really need lots of work to do, because Rtems supports so many architecture and 
BSP which should be adapted to BUS SPACE API, and it also should not influence the nature
API of Rtems. About the method to implement it, there're two potential way in my opinion
: 
1). Each architecture and BSP must implement its own Bus API, either function or macros 
is ok. So the score code will not be changed. 
2). The score code implement the Bus API framework, and each architecture and BSP 
implement its own specific bus functions, then register these functions as call back of
Bus API.
What is your opinion?
> I understand there is work being done on this project how-ever I think the work is limited to a couple of architectures. I do not know the timeline for this work, how-ever if it was in the master repo by the time GSoC started there would be projects to add support for those architectures not added in the first pass.
> 
So first we can chose a specific architecture and BSP to adapt the Bus API, Then apply to other
architectures and BSPs.
> Chris

Wei Yang
Best Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20120208/3a6d60e5/attachment.html>