|Re: [pok-devel] ARINC-653 intrapartition communication compatibility|
[ Thread Index |
| More lists.tuxfamily.org/pok-devel Archives
this discussion reminds me I wanted to ask this question to the pok developpers: why wouldn't we use branches to organize this type of new contribution?
If we had a branch for Maxim's devs we could easily experiment the compatibility with Ocarina or RAMSES. Similarly, I have a student working on pok and it would probably be easier for him as well to have his own branch until we reach the point to decide if we must integrate his code in the trunk.
What is your opinion about this?
----- Mail original -----
De: "Julien Delange" <julien@xxxxxxxxx>
Envoyé: Samedi 22 Février 2014 02:35:20
Objet: Re: [pok-devel] ARINC-653 intrapartition communication compatibility
That sounds great! Please let us know how we can adapt the code generation
layer from Ocarina! Also, do you plan to commit to test suite?
Thanks for your contribution, I am looking forward to integrate that in the
main code base !
On Fri, Feb 21, 2014 at 4:53 PM, Maxim Malkov <malkov@xxxxxxxxx> wrote:
> On 02/20/2014 08:30 PM, Maxim Malkov wrote:
> > I'll post a message describing changes that I've already made
> > tomorrow. Maybe it will be immediately obvious what can possibly break.
> I probably forgot many changes that I've made, but here's at least some
> of them:
> ARINC layer:
> * buffers, blackboards, semaphores and events can no longer be created
> in normal operating mode
> * many improvements in invalid parameter handling
> * internal POK error code are correctly mapped to ARINC ones
> * GET_TIME and TIMED_WAIT
> * memcmp no longer compares four times more data than requested
> * not a change in libc itself, but looks like I eliminated all the code
> that ever used terrible streq
> Middleware layer:
> * buffers, blackboards, semaphores and events names are no longer static
> * Each buffer message now contains message length (i.e. RECEIVE_BUFFER
> returns the same message length that has been passed to SEND_BUFFER)
> * Non-blocking semaphore check
> * Basic preemption locking (+ ARINC interface)
> * Lockobj fixes (some code paths were incorrect wrt. spinlock, certain
> syscalls returned incorrect value) and improvements (nonblocking trylock)
> * Some fixes in the scheduler
> Bottom line: after all the fixes, the only problems with intrapartition
> services I'm aware of are releated to missing functionality in scheduler
> (mostly, priority levels). I still have to test interpartition services,
> error handling and misc. stuff.
> Maxim Malkov
> Software Engineering Department, ISPRAS