On Fri, Sep 2, 2011 at 7:05 PM, YOSHIDA Shigeru <yshigeru@xxxxxxxxx> wrote: > Hi, > > I'm also developing VxWorks and Linux application in my job. > To port VxWorks application to Linux, our approach is to map > individual VxWorks tasks to POSIX threads. > > I consider entire VxWorks address space as one Linux process > address space. > > 2011/9/2 Raz <raziebe@xxxxxxxxx>: >> 1. vxworks rt priority range scales up to 255 and not 100 which is not enough. >> >> Compiling kernel with RT_MAX_PRIO set to 255 ( 3.0 even >> without preemprt rt ) and executing cyclictest crashes kernel >> ( NULL pointer in pick_next_task_rt +0x88 ). So naive >> approach doesn't work. >> >> How do i increase MAX_RT_PRIO to higher value, even in the >> cost of recompiling an entire system ( all os user space >> code is recompiled with a sanitized kernel headers ). > > Do you really use all 255 VxWorks priority range? > If your application's priority range can map to Linux's 100 priority range, > I recommend to do so. i wish to estimate the efforts, fixing and a 15-years old application versus fixing linux OS. I am not so sure the latter is such a bad idea. > >> 2. global critical section >> >> vxworks does not have the notion of a virtual address space. >> so code that is "user space" >> oriented is executing side by side to an interrupt , this >> leads to "cli"-like global locks >> in a vxworks world. >> >> so in linux.. >> one solution is to "iopl(3)" and then "sti/cli" in user space >> , this is good for UNI processors machines, >> but assuming preempt-rt will run smp machines it is not good. >> also, disabling interrupts is considered bad >> practice in preempt-rt. >> another solution is to increase the executing thread priority >> to the highest value possible, i believe it is >> theoretically correct assuming i have full control over the >> entire operating system. >> >> anyone experienced with sort of problems ? or tried any of the >> above with success ? > > In our task-to-pthread mapping, we use pthread mutex to mutual > execution. mutual exclusion is not the case here. i do not have a sync object like mutex,spin lock . >> 3. vxworks target shell. >> >> vxworks provides a shell-like access to its system, and since >> all tasks share address space it is possible >> to access all globals in the c code just like in gdb, examine >> stacks and so on without disturbing the >> rt task whatsoever. >> >> I need this feature in linux per-process. >> At the moment i did not find anything like vx-target shell in >> linux. gdb/ptrace is out of the question as >> they influence the rt task behavior. >> Currently I think to create a thread that is part of to the >> process address space. this thread is based on libcli, >> and it it means should integrate it with pstack code and nm code. >> >> so before i start writing piles of code, any other ideas ? > > In our task-to-pthread mapping, we can use gdb, and can do > something like VxWorks shell. when gdb attaches a task is suspends all threads . ptrace affects incoming signals to traced task. i need to have something else. > thanks. > -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
