Gsoc 2012 project

[Chris Johns]

On 9/02/12 1:46 AM, Yang Wei wrote:
>
>
> 发自我的 iPad
>
> 在 2012-2-8，7:54，Chris Johns <chrisj at rtems.org
> <mailto: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?*

Option 2 is closer to what the bus API provides and what we require. We 
require an RTEMS score API the BSD API (or a subset) maps to. An 
architecture or BSP can provide a specific bus interface (see 
bus_space_tag) and devices on that target supported by the BSP are 
connected to that bus. The driver does not know or understand the 
specific of the bus, just the bus API.

The immediate main purpose of the bus api is to support BSD drivers with 
minimal source code changes. In time I hope RTEMS drivers will move to 
use the same API.

>> 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.

The score API and how it relates to the BSD API is the critical first 
step. Next is implementing the api on a single architecture and showing 
BSD drivers can work with it. This implies porting of some BSD software 
such as a new networking stack or the USB stack. Once stable and 
functional more architectures can be added.

There is code existing in RTEMS that shows architecture specific 
implementations of the bus_space API. For example ..

http://git.rtems.org/libbsdport/tree/bsd_eth_drivers/libbsdport/bus.h
https://www.rtems.org/bugzilla/show_bug.cgi?id=1601

Chris