exposing core objects through RTEMS classic API, POSIX or ITRON

Andrei Dimitrief-Jianu andrei.dimitrief.jianu at gmail.com
Mon Oct 15 02:40:27 UTC 2012


On Fri, Oct 12, 2012 at 9:54 AM, Gedare Bloom <gedare at rtems.org> wrote:
> Hi,
>
> I would prefer to discuss these kinds of development-related issues on
> the rtems-devel list. Perhaps you meant to and it was an oversight. If
> you don't mind, please CC any further replies or followup there.
>
> As to your question, it depends. We want to share as much of the
> implementation as possible among the various APIs. But if something is
> only supported by a custom RTEMS API then usually it will just go
> directly to the "classic" API. I'm not sure if posix has any kind of
> event notification mechanisms that might be layered over a supercore
> event manager. By the way, ITRON is deprecated and you do not need to
> worry about it.
>
> The other thing to consider is whether supercore code needs to use the
> manager. If so, then the manager has to reside at the supercore layer,
> because it is a violation to "upcall" from supercore to an API.
>
> I don't know how related this is, but there is an open project looking
> for a volunteer to provide event support within the kernel:
> http://wiki.rtems.org/wiki/index.php/RTEMSSystemEvents -- these kernel
> events are probably more than you are thinking about right now, but I
> could see a supercore kernel event subsystem with a classic API event
> notification/delivery mechanism layered over it.
>
> -Gedare
>

Gedare,

At this point I need an eventflag and a read-write lock for a framework
written on top of RTEMS. I would rather see them implemented as RTEMS managers.

I will gladly look into the kernel events once I am done.

Regards,
Andrei.


>
> On Fri, Oct 12, 2012 at 9:19 AM, Andrei Dimitrief-Jianu
> <andrei.dimitrief.jianu at gmail.com> wrote:
>> Hello,
>>
>> After looking at the code of some of the RTEMS managers I see that the
>> general approach seems to be to have first a core object implemented,
>> and then have a manager defined for the RTEMS API.
>>
>> I guess my question is: should a proper implementation for a manager
>> consist of a core object and 3 wrappers that would expose the core
>> object through RTEMS API, POSIX and ITRON?
>>
>> Thanks,
>> Andrei.



More information about the devel mailing list