Date: Tue, 15 Nov 2005 09:59:57 +0530 From: "Kamal R. Prasad" <kamalp@acm.org> To: John Giacomoni <John.Giacomoni@colorado.edu> Cc: freebsd-hackers@freebsd.org Subject: Re: Sharing the same VM address space between Kernel and UserSpace Message-ID: <53B48211-614A-43F9-89B0-C0A2DE7F168B@acm.org> In-Reply-To: <D07013F4-5402-4A78-88BE-37EAC73255C4@colorado.edu> References: <AA4AEE17-32CC-4D47-96C0-0B0B0BC13B68@colorado.edu> <4378FA26.8040604@samsco.org> <D07013F4-5402-4A78-88BE-37EAC73255C4@colorado.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 15-Nov-05, at 3:58 AM, John Giacomoni wrote: > > On Nov 14, 2005, at 1:57 PM, Scott Long wrote: > > >> John Giacomoni wrote: >> >> >>> I am in need of a way to share memory between kernel space and >>> possibly >>> multiple different user-space processes for an extended period of >>> time. >>> This memory would need to be a single unpageable region. >>> I am using the vm routines as cribbed from mmap, however I'd like >>> the >>> address spaces to be viewed as the same regardless of which >>> process I'm >>> in to avoid swizzling pointers as I'm storing data structures in the >>> shared memory region. >>> I imagine I'd need to find a way to expose part of the kernel >>> address >>> space to user space to accomplish this. >>> Is there a way to do this? >>> thanks >>> John G >>> >> >> If you get this working then it'll be very useful for the syspage >> support that was talked about recently. >> >> The kernel can access addresses in the user space so long as they >> are wired and won't cause a fault. Thus I imagine that you >> only need to allocate the memory, wire it, mark it with the >> appropriate >> page permissions, and reserve a user address range for it in the >> process map. I'd look at the process exec path in the kernel for >> places to hook in. The only other trick then is how to let the user >> process know the address for this magic region. An easy way would be >> to store it in a sysctl that can be read at runtime. A harder way >> would >> be to have the kernel dummy up an elf segment in the image activator >> code that the dynamic linker could read and put into a global >> variable >> for the program to access. >> >> Scott >> >> > > Which thread/list was the syspage support discussed? > (I did a quick search in my freebsd-hackers mailbox and didn't find > it) > > As for my problem I'm not sure that the kernel being able to access > userpages > is quite what is needed. The first reason is that if there are two > processes > trying to map the same region it would be problematic if one of > them had > allocated something in the same area of the heap as the shared > memory region Typically, the address range for heap is different from that of shared memory segment. Im not sure of freebsd -but for AIX what Im saying is true. So, unless you have allocated another shared memory object, MAP_FIXED should suffice to get the same address across user processes. > resides. This suggests that to avoid swizzling the region needs to > be in an > address region where the user-space processes will never allocate > in (kernel). > The other reason is that the kernel code needs to be able to > function using > the shared memory without a user-space process being attached at > all times. > > So the question is, is it possible to mark wired kernel pages as > being accessible > to a user-space process without triggering a context switch? > How about you bring in a kernel process to access the mmap'ed file/ shmid? regards -kamal > John G > > -- > > John.Giacomoni@colorado.edu > University of Colorado at Boulder > Department of Computer Science > Engineering Center, ECCR 1B05 > 430 UCB > Boulder, CO 80303-0430 > USA > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers- > unsubscribe@freebsd.org" > Kamal R. Prasad UNIX systems consultant http://www.kamalprasad.com/ kamalp@acm.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53B48211-614A-43F9-89B0-C0A2DE7F168B>