Dmitry Adamushko wrote:
> > ...
> >
> > This cannot happen in async mode, since the output would be
buffered and
> > printk() never called on behalf of the preempted handler.
> >
> >>
> >> let's say at the (*) point
> >>
> >> void __ipipe_flush_printk (unsigned virq)
> >> {
> >>
please see comments below...
>
> Another approach is about dropping the non-atomic update sequence
> that hurts, tolerating
> null runs of the virq when the seldom preemption case is seen, but
> without requiring hw
> interrupt masking to protect the shared stuff. Livelocking Linux
> inside
Hi,
When I use the search function in the online API documentation, firefox
(1.0.7) downloads search.php. I guess something is fouled up.
Nacho.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Ignacio García Pérez wrote:
RT_PIPE_MSG *m = rt_pipe_alloc(sizeof(mystruct_t));
mystruct_t *p = (mystruct_t *)P_MSGPTR(m);
p->whatever1 = X;
p->whatever2 = X;
rt_pipe_send(&mypipe, m, sizeof(mystruct_t), P_NORMAL);
If this is correct, why do I have to specify the size of mystruct_t
*twice*. Can'
Ignacio García Pérez wrote:
Hi,
Suppose I have a kernel rt task that samples data at a certain rate and
writes it as messages into a rt pipe, from which it is read by a user
space non rt program.
I want to limit the number of messages that are put into the pipe,
because otherwise if the user sp
Philippe Gerum wrote:
> Ignacio García Pérez wrote:
>
RT_PIPE_MSG *m = rt_pipe_alloc(sizeof(mystruct_t));
mystruct_t *p = (mystruct_t *)P_MSGPTR(m);
p->whatever1 = X;
p->whatever2 = X;
rt_pipe_send(&mypipe, m, sizeof(mystruct_t), P_NORMAL);
If this is correct, wh
Hello,
enclosed please find a patch that hopefully adds so desired functionality. I have made various tests with it just now and it seems to work fine.
A size of the bitmap is dependent on XNPIPE_NDEVS parameter in the same vein as xnpipe_states depends on it; so hopefully that is what you have
Dmitry Adamushko wrote:
Hello,
enclosed please find a patch that hopefully adds so desired
functionality. I have made various tests with it just now and it seems
to work fine.
Sounds good.
A size of the bitmap is dependent on XNPIPE_NDEVS parameter in the same
vein as xnpipe_states depe
Ignacio García Pérez wrote:
Philippe Gerum wrote:
Ignacio García Pérez wrote:
RT_PIPE_MSG *m = rt_pipe_alloc(sizeof(mystruct_t));
mystruct_t *p = (mystruct_t *)P_MSGPTR(m);
p->whatever1 = X;
p->whatever2 = X;
rt_pipe_send(&mypipe, m, sizeof(mystruct_t), P_NORMAL);
If this is correct, why d
Dmitry Adamushko wrote:
> > ...
> >
> > This cannot happen in async mode, since the output would be
buffered and
> > printk() never called on behalf of the preempted handler.
> >
> >>
> >> let's say at the (*) point
> >>
> >> void __ipipe_flush_printk (unsigned virq)
> >> {
> >>
please see comments below...
>
> Another approach is about dropping the non-atomic update sequence
> that hurts, tolerating
> null runs of the virq when the seldom preemption case is seen, but
> without requiring hw
> interrupt masking to protect the shared stuff. Livelocking Linux
> inside
Hi,
When I use the search function in the online API documentation, firefox
(1.0.7) downloads search.php. I guess something is fouled up.
Nacho.
Ignacio García Pérez wrote:
RT_PIPE_MSG *m = rt_pipe_alloc(sizeof(mystruct_t));
mystruct_t *p = (mystruct_t *)P_MSGPTR(m);
p->whatever1 = X;
p->whatever2 = X;
rt_pipe_send(&mypipe, m, sizeof(mystruct_t), P_NORMAL);
If this is correct, why do I have to specify the size of mystruct_t
*twice*. Can'
Ignacio García Pérez wrote:
Hi,
Suppose I have a kernel rt task that samples data at a certain rate and
writes it as messages into a rt pipe, from which it is read by a user
space non rt program.
I want to limit the number of messages that are put into the pipe,
because otherwise if the user sp
Philippe Gerum wrote:
> Ignacio García Pérez wrote:
>
RT_PIPE_MSG *m = rt_pipe_alloc(sizeof(mystruct_t));
mystruct_t *p = (mystruct_t *)P_MSGPTR(m);
p->whatever1 = X;
p->whatever2 = X;
rt_pipe_send(&mypipe, m, sizeof(mystruct_t), P_NORMAL);
If this is correct, wh
Hello,
enclosed please find a patch that hopefully adds so desired functionality. I have made various tests with it just now and it seems to work fine.
A size of the bitmap is dependent on XNPIPE_NDEVS parameter in the same vein as xnpipe_states depends on it; so hopefully that is what you have
Dmitry Adamushko wrote:
Hello,
enclosed please find a patch that hopefully adds so desired
functionality. I have made various tests with it just now and it seems
to work fine.
Sounds good.
A size of the bitmap is dependent on XNPIPE_NDEVS parameter in the same
vein as xnpipe_states depe
17 matches
Mail list logo
