Hello fellow kernel-developers,
Does anyone know the steps required to implement ring-buffers for the application level?
I studied the kernel code a bit, but am afraid I don't quite understood the inner working of user heap.
Ring buffers in userland
-
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
https://en.wikipedia.org/wiki/Circular_ ... timization
Analog to create_ring_buffer in kernel, but accessible from application/libraries.
Analog to create_ring_buffer in kernel, but accessible from application/libraries.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
After reading this post I managed to get two adjacent virtual pages mapped to the same physical page, RW accessible from the application:
May be it makes sense to create create_ring_buffer_user and create_ring_buffer_common and move most part of create_ring_buffer to the latter one.
Code: Select all
stdcall user_alloc, 0x2000
<-lin
call alloc_page
<-phys
stdcall map_page, lin, phys, PG_UWR
stdcall map_page, lin+0x1000, phys, PG_UWR
Problem I see is that "stdcall user_alloc" gives us virtual memory that is already mapped to physical memory.dunkaist wrote:After reading this post I managed to get two adjacent virtual pages mapped to the same physical page, RW accessible from the application:May be it makes sense to create create_ring_buffer_user and create_ring_buffer_common and move most part of create_ring_buffer to the latter one.Code: Select all
stdcall user_alloc, 0x2000 <-lin call alloc_page <-phys stdcall map_page, lin, phys, PG_UWR stdcall map_page, lin+0x1000, phys, PG_UWR
(And didn't find yet how/where it is mapped.)
Also, how to undo everything when we're done?
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
Doesn't user_alloc allocates memory lazily, i.e. only virtual pages immediately, physical pages in PF handler?hidnplayr wrote:Problem I see is that "stdcall user_alloc" gives us virtual memory that is already mapped to physical memory.
(And didn't find yet how/where it is mapped.)
If this is the case, then it is clear why you didn't find where user_alloc works with physical pages.
Again, I'm just interpreting this post.hidnplayr wrote:Also, how to undo everything when we're done?
I see that user_free calls free_page too. Isn't it enough?
It seems you are right. Allocation is done in "page_fault_handler" in memory.incdunkaist wrote:Doesn't user_alloc allocates memory lazily, i.e. only virtual pages immediately, physical pages in PF handler?hidnplayr wrote:Problem I see is that "stdcall user_alloc" gives us virtual memory that is already mapped to physical memory.
(And didn't find yet how/where it is mapped.)
If this is the case, then it is clear why you didn't find where user_alloc works with physical pages.
It explains the magic bit flag '2' sometimes referred to in the code as 'reserved'.
Thanks!
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
Who is online
Users browsing this forum: No registered users and 1 guest