Hi Norm,
Possibly there is a simpler way from userspace. I think that as long as
your root you can open /dev/mem and get at the kernel address space
directly ??
Regards, Stuart
"Dresner, Norman A." wrote:
>
> Todd.
>
> It's always seemed to me to be much safer and simpler to implement ioctl(2)
> functions to get & set parameters or data blocks.
>
> Also consider mmap(2) to give users access to kernel data segments (always a
> risky proposition which is why I favor ioctl.
>
> Finally, using, for example,
> append="mem=125m"
> I can reserve the top 5 MB of memory in a 128 MB machine and then use it as
> shared memory "directly." There are techniques that allow using the same
> address for these blocks in both the kernel & user-land so data structures
> can contain valid pointers.
>
> Norman Dresner
> Fellow Systems Engineer
> Radar Systems Engineering Department
> Electronic Systems and Sensors Segment
> Northrop Grumman Corporation
> Baltimore-Washington International Airport
> 7323 Aviation Boulevard
> Baltimore Maryland 21240
>
> 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: [EMAIL PROTECTED]
> Afternoons: [EMAIL PROTECTED]
>
> > -----Original Message-----
> > From: Gearheart, Todd [SMTP:[EMAIL PROTECTED]]
> > Sent: Wednesday, February 07, 2001 11:15 AM
> > To: 'Stuart Hughes'
> > Cc: '[EMAIL PROTECTED]'
> > Subject: RE: [rtl] beginner question
> >
> > You can also "access" private data in kernel address space from user mode
> > programs, by employing a simple trick. A user program can request access
> > to
> > a section of private kernel address space (via fifos, shared memory, or
> > whatever). Then a kernel module can copy the requested section of the
> > kernel
> > private address space "needed in user space" into shared memory. Then user
> > mode program can view/modify the shared memory area and signal/indicate
> > the
> > change(s) made. Finally the kernel module can take care of "updating" the
> > changes back into the kernel private address space (from the shared memory
> > area).
> >
> > I was able to implement a similar "swapping technique" in my simulator
> > application. It allows access to ALL kernel real-time storage from the
> > user
> > side as well...
> >
> > Regards,
> > Todd Gearheart
> >
> > -----Original Message-----
> > From: Stuart Hughes [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, February 07, 2001 7:43 AM
> > To: Stefano Picerno
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: [rtl] beginner question
> >
> >
> > Stefano Picerno wrote:
> > >
> > > If I have two different realtime modules, can I access the address space
> > > of one of them from the other?
> > >
> > > I mean, if task A have some private data at 0x1234578, can task B read
> > the
> > > same data at the same address?
> >
> > Yes, they occupy the same kernel address space.
> >
> > Regards, Stuart
> > -- [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/
