Interaction with L4

Norman Feske norman.feske at ...1...
Fri Jan 29 14:48:21 CET 2010

Hi Peter,

> In trying to map the buffer that has been allocated in the kernel, I keep
> getting a page fault, which would suggest that the kernel memory has not been
> mapped. This sampling buffer always gets allocated at physical address 4456448,
> while the size of the buffer is 262144. I figured i'd try following the code in
> that file mentioned above. The code currently have is the following:
> 	enum{SAMP_PHYS = 0x440000, SAMP_SIZE = 0x40000};
> 	Io_mem_connection sampbuffer(SAMP_PHYS, SAMP_SIZE);
> 	samples =
> (sampling_buffer_t*)env()->rm_session()->attach(sampbuffer.dataspace());
> where samples is of type sampling_buffer_t*. If you have the iguana source that
> came with OKL4 v2, this type is the same type as the trace_buffer_t. I strongly
> suspect this code is not correct for mapping the kernel memory to user space.
> How can i go about mapping this memory so that I can read the contents of this
> memory so as to perform processing?

Is 'sampbuffer' declared as a local variable? If yes, this would
explain the problem. When the program leaves the scope where
'sampbuffer' is declared, the destructor of 'Io_mem_connection'
gets executed. By default, this destructor closes the session such
that the session's dataspace gets destroyed. You can solve this
problem in two ways. First, it is possible to tell 'sampbuffer'
to keep the session open after the destuctor is called:


Another solution would be declaring 'sampbuffer' als local static
variable. Once constructed, one object instance will exist for the
whole runtime of the program. Of course, you could also explicitely
manage the lifetime of 'sampbuffer' by using the 'new' operator but
in most cases (if you need one session during the whole execution
time), a declaring the connection object as local static variable
is most convenient.


More information about the users mailing list