On Tue, Jan 18, 2000 at 08:21:01PM -0800, Robert Kavaler wrote:
> > > 4. Added mmap and ioctl functions to the posix interface, if that makes
> > > sense.
> >
> > What do they do?
>
> These functions just call device specific functions. For the FIFOS there are no
>device specific functions (although changing the size of
> a FIFO should be an ioctl through the Posix interface). The main reason I use mmap
>is to implement a driver for a PCI device that needs
> its memory mapped. Obviously, if the mmap call has to call the kernel mmapper then
>it can only be done during initialization (which is my
> case). The reason I decided to implement mmap through the posix interface was
>because I compile my module for use in either user space
> (for debugging) or the real-time kernel.
I like the idea, but want some error checks. Also I'm trying to figure out a
good interface for "run function f in linux kernel mode" which is easy to implement
but needs to fit in well -- I'm trying to figure out a way to make this a posix call.
In any case, this would make it possible to run the ioctl in either mode although
I want to make it obvious that the call may introduce a non-rt delay.
> > > I also have a question regarding the both my reference counter callback
> > > and the standard fifo user callback. The way I see it implemented, the
> > > callbacks run at the linux kernel level and not the realtime kernel
> > > level. Thus, either callback can be interrupted by the realtime kernel
> > > and not run to completion until after the rt tasks are executed. Thus,
> > > the callback code is not actually synchonized to the realtime kernel.
> > > This seems like a problem. How can I synchonize the callback to a rt
> > > kernel task?
> >
> > Can you be more precise about what you want?
> > The 2.0.pre1 has new RT callbacks with fifo, but perhaps this is not what you want?
>
> I want to be sure that the RT kernel does not interrupt while the callback is being
>run.
The best method is for your callback to specifically disable interrupts using
rtl_no_interrupts
and
rtl_restore_interrupts
If you want to be smp safe you need a spinlock too. In general, atomicity of
callbacks is not needed and I hate to add it by default.
> > > By the way, I am using the beta13 release of RTLinux with a 2.2.11
> > > kernel.
Upgrade! It's surprising that it is usable.
--- [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/
