<html><head></head><body bgcolor="#FFFFFF"><div><br><br>发自我的 iPad</div><div><br>在 2012-2-8，7:54，Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>> 写道：<br><br></div><div></div><blockquote type="cite"><div><span>On 8/02/12 1:34 AM, yangwei weiyang wrote:</span><br><blockquote type="cite"><span>Hi all:</span><br></blockquote><blockquote type="cite"><span> From the mail of Joel I know that the Google summer of code 2012 is</span><br></blockquote><blockquote type="cite"><span>going to start and RTEMS will be absolutely a member of organizations.</span><br></blockquote><blockquote type="cite"><span>There are lots of projects i am interested in from the Wiki open project</span><br></blockquote><blockquote type="cite"><span>section. The most favorite one for me is "Bus Space API". So i want to</span><br></blockquote><blockquote type="cite"><span>know as much information as possible.</span><br></blockquote><span></span><br><span>Thanks for looking.</span><br><span></span><br><blockquote type="cite"><span> First i have read "Bus Space API" section carefully at the Wiki,</span><br></blockquote><blockquote type="cite"><span>And also know some basic backgroud through the IRC log. The bus_space</span><br></blockquote><blockquote type="cite"><span>API is originally from NetBSD, its goal is to allow a single driver</span><br></blockquote><blockquote type="cite"><span>source file to manipulate a set of devices on different system</span><br></blockquote><blockquote type="cite"><span>architectures, and to allow a single driver object file to manipulate a</span><br></blockquote><blockquote type="cite"><span>set of devices on multiple bus types on a single architecture. It is</span><br></blockquote><blockquote type="cite"><span>implemented in the BSP layer and the architecture layer, that means</span><br></blockquote><blockquote type="cite"><span>different architecture and machine must implement its own bus space type</span><br></blockquote><blockquote type="cite"><span>and</span><br></blockquote><blockquote type="cite"><span>functions. But the goal of "Bus Space API" project is to easing the</span><br></blockquote><blockquote type="cite"><span>ports of BSD drivers to RTEMS, so in order to realize its goal, should</span><br></blockquote><blockquote type="cite"><span>we port bus_space API to RTEMS BSP layer and architecture layer or adapt</span><br></blockquote><blockquote type="cite"><span>the bus_space API in the RTEMS score which make BSP layer and</span><br></blockquote><blockquote type="cite"><span>architecture layer unchanged or changed minimum?</span><br></blockquote><blockquote type="cite"><span> So i want to know more information about this project, are there</span><br></blockquote><blockquote type="cite"><span>some protential mentors to help me?</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><span></span><br><span>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.</span><br><span></span><br></div></blockquote>This project really need lots of work to do, because Rtems supports so many architecture and <div>BSP which should be adapted to BUS SPACE API, and it also should not<b> influence the nature</b></div><div><b>API of Rtems. About the method to implement it, there're two potential way in my opinion<br></b></div><div><div><b>: </b></div><div><b>1). Each architecture and BSP must implement its own Bus API, either function or macros </b></div><div><b>is ok. So the score code will not be changed. </b></div><div><b>2). The score code implement the Bus API framework, and each architecture and BSP </b></div><div><b>implement its own specific bus functions, then register these functions as call back of</b></div><div><b>Bus API.</b></div><div><b>What is your opinion?</b></div><div><blockquote type="cite"><div><span>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.</span><br><span></span><br></div></blockquote>So first we can chose a specific architecture and BSP to adapt the Bus API, Then apply to other</div><div>architectures and BSPs.<br><blockquote type="cite"><div><span>Chris</span><br></div></blockquote><br></div></div><div>Wei Yang</div><div>Best Regards</div></body></html>