Asynchrounous/non-blocking sends from userspace

[Andreas Bock]

Dear community,

We are implementing a new server in MINIX 3.2.0 for event-based profiling purposes. It is designed to receive messages from other servers and userland processes to write profiling data to a file.

We are currently focusing on tracing system calls.

We want to send these messages asynchronously, but have not succeeded in finding any suitable API.

Is it possible to grant permission for userspace processes to make non-blocking sends using sendnb(), for instance?

Furthermore, we want servers such as PM to "forward" all incoming messages to our profiling server, while preserving the origin (original sender) of the message.
This way we can log what processes are performing which system calls.

Is there a way of retaining this information without extending the message struct?

Thank you.

Yours Sincerely,

Andreas Bock & Asbjørn Thegler

[Tomas Hruby]

Hi,

> We are implementing a new server in MINIX 3.2.0 for event-based profiling
> purposes. It is designed to receive messages from other servers and
> userland processes to write profiling data to a file.
> We are currently focusing on tracing system calls.
>
> We want to send these messages asynchronously, but have not succeeded in
> finding any suitable API.

What messages do you want to send where?

> Is it possible to grant permission for userspace processes to make
> non-blocking sends using sendnb(), for instance?

It is not allowed for ordinary user processes

> Furthermore, we want servers such as PM to "forward" all incoming messages
> to our profiling server, while preserving the origin (original sender) of
> the message.
> This way we can log what processes are performing which system calls.
>
> Is there a way of retaining this information without extending the message
> struct?

No. The source field is set by the kernel. However, I am finishing a
new asynchronous messaging mechanism which bypasses kernel and allows
sending larger messages between two servers/drivers. It would serve
your purpose well, I guess. I send you the patches once I polish them,
hopefully in a few days, and you can be my guinea pig :)

Note that PM does not see all system calls, there is also VFS and VM.

Cheers, T.

[Andreas Bock]

Hello,

On Sun, May 20, 2012 at 7:30 PM, Tomas Hruby <thr...@gmail.com> wrote:

Hi,

> We are implementing a new server in MINIX 3.2.0 for event-based profiling
> purposes. It is designed to receive messages from other servers and
> userland processes to write profiling data to a file.
> We are currently focusing on tracing system calls.
>
> We want to send these messages asynchronously, but have not succeeded in
> finding any suitable API.

What messages do you want to send where?

 

Ideally we would like to send all types of messages to the profiling server. We would like to be able to insert probes in the existing servers that forward a copy of the messages they receive to the profiling server. We hope to extend this so that users may send profiling data directly to the server using a well-defined API.

> Is it possible to grant permission for userspace processes to make
> non-blocking sends using sendnb(), for instance?

It is not allowed for ordinary user processes

 

Thanks for the clarification.

> Furthermore, we want servers such as PM to "forward" all incoming messages
> to our profiling server, while preserving the origin (original sender) of
> the message.
> This way we can log what processes are performing which system calls.
>
> Is there a way of retaining this information without extending the message
> struct?

No. The source field is set by the kernel. However, I am finishing a
new asynchronous messaging mechanism which bypasses kernel and allows
sending larger messages between two servers/drivers. It would serve
your purpose well, I guess. I send you the patches once I polish them,
hopefully in a few days, and you can be my guinea pig :)

This would fit our needs very well, we are looking forward to testing it. :)

Note that PM does not see all system calls, there is also VFS and VM.

Cheers, T.

Thank you for the response!

Yours Sincerely,

Andreas Bock & Asbjørn Thegler

--
You received this message because you are subscribed to the Google Groups "minix3" group.
To post to this group, send email to min...@googlegroups.com.
To unsubscribe from this group, send email to minix3+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/minix3?hl=en.

[Tomas Hruby]

On Mon, May 21, 2012 at 12:10:19PM +0200, Andreas Bock wrote:
> Hello,
>
> On Sun, May 20, 2012 at 7:30 PM, Tomas Hruby <thr...@gmail.com> wrote:
>
> > Hi,
> >
> > > We are implementing a new server in MINIX 3.2.0 for event-based profiling
> > > purposes. It is designed to receive messages from other servers and
> > > userland processes to write profiling data to a file.
> > > We are currently focusing on tracing system calls.
> > >
> > > We want to send these messages asynchronously, but have not succeeded in
> > > finding any suitable API.
> >
> > What messages do you want to send where?
> >
>
> Ideally we would like to send all types of messages to the profiling
> server. We would like to be able to insert probes in the existing servers
> that forward a copy of the messages they receive to the profiling server.
> We hope to extend this so that users may send profiling data directly to
> the server using a well-defined API.

You could tweak kernel so that it sends all the messages to your
server, but you would need to use a different mechanism than what the
current IPC allows, add a new sort of communication between the kernel
and your server. I am not sure how straight forward it would be.

> > > Furthermore, we want servers such as PM to "forward" all incoming
> > messages
> > > to our profiling server, while preserving the origin (original sender) of
> > > the message.
> > > This way we can log what processes are performing which system calls.
> > >
> > > Is there a way of retaining this information without extending the
> > message
> > > struct?
> >
> > No. The source field is set by the kernel. However, I am finishing a
> > new asynchronous messaging mechanism which bypasses kernel and allows
> > sending larger messages between two servers/drivers. It would serve
> > your purpose well, I guess. I send you the patches once I polish them,
> > hopefully in a few days, and you can be my guinea pig :)
> >
>
> This would fit our needs very well, we are looking forward to testing it. :)

Good. Just to double check, do you use recent Minix?

T.