I too have been seeking new/different ways to share memory between kernel
and user mode tasks. I have several existing application's) that must be
ported to real-time Linux. Each app. consists of a large number of FORTRAN
modules that are all designed to communicate via several shared COMMONs
areas. My port isn't allowed to change the functionality of the target app.
Thus I must preserve the original intent by NOT changing it's
design/functionality.
Obviously, part of my port requires the final app to be inserted as a kernel
module into the RTLinux context. Thus I must intermix the FORTRAN modules
with several small C functions. On the kernel side, I can easily get C and
FORTRAN to co-exist. This includes sharing the same commons area pointers,
making function and subroutine calls from each side, etc.
But I also need to be able to supply several user mode programs with
pointers to the FORTRAN commons areas. Since the FORTRAN code in my app(s)
doesn't directly support dynamic allocation of FORTRAN commons. Space is
allocated and assigned at run/load time (by insmod???) for all of the COMMON
block areas. My dilemma is how to remap these commons blocks to user mode
pointers.
One possible approach would be to write a driver, and use ioctl calls to
copy bits of memory between mirrored buffers existing in user and kernel
space. But this requires a lot of sequencing/control work - and uses more
processor time for the copies to and fro. Since modules on both sides need
to do extensive examine/change operations each iteration. The simpler
(original) shared memory approach is more desirable.
A bit of grepping has revealed that sys_create_module() (in kernel\module.c)
uses the function module_map() to allocate memory for modules when loaded.
The function module_map() is #defined to be vmalloc() in the
include/asm-i386/pgtable.h header file. Rubini's book makes reference to
methods for remapping virtual addresses using his example "skullv". "skullv"
remaps memory it first allocates using vmalloc - Thus I wonder if
modifications to this code might allow me to remap my FORTRAN COMMONS areas
to user space? Such an approach would not require any kernel hacking - but
could exist as a device driver. User code could then call the device driver
to return remapped pointers to vmalloc()ed buffers in kernel space...
Could this work or is there something I am missing here???
note: Rubini also talks about modifing "scullv" to remap addresses returned
by vremap/ioremap to user space as well.
-----Original Message-----
From: Dresner, Norman A. [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 25, 2001 9:38 AM
To: '[EMAIL PROTECTED]'
Subject: RE: [rtl] How to do shared memory with pointers?
What is truly disappointing is that (as I understand it) using mmap() to map
a real address to a specified virtual location can't be used in the kernel
(or am I missing something?) Also I've tried to use mmap() to address (in
user-space) reserved memory to the same address that ioremap() gives to a
kernel module and it's failed.
Norman Dresner
Fellow Systems Engineer &(SGI) Advanced Signal Processing Laboratory
Administrator
Radar Systems Engineering Department
Electronic Systems and Sensors Segment
Northrop Grumman Corporation
MS 520
Box 746
Baltimore MD 21203
Voice: (410) 993 - 2096 Mornings; all-day voice-mail
(410) 969 - 8068 Afternoons with answering machine
FAX: (410) 993 - 8084 On-site
(410) 969 - 8068 Afternoons; call first to arrange
E-Mail: Mornings: mailto:[EMAIL PROTECTED]
Afternoons: mailto:[EMAIL PROTECTED]
> -----Original Message-----
> From: C. W. Wright (1698) [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, April 25, 2001 8:00 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [rtl] How to do shared memory with pointers?
>
>
>
> > I guess I'm a little disappointed. I would of though the kernel would be
> > able to return 'almost' any unused virtual address to either the
> realtime
> > or normal linux task.
>
>
> It can do what you want. See "man mmap" and look at the MAP_FIXED and
> MAP_SHARED. Note the verbage "start must be a multiple of the page-size."
> The program will not work unless the address you request is on a page
> boundary, and will core-dump with a page fault.
>
> -Wayne
> -- [rtl] ---
> To unsubscribe:
> echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
> --
> For more information on Real-Time Linux see:
> http://www.rtlinux.org/rtlinux/
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
