On Thu, 20 May 1999, Sugat Jain wrote:
> I decided to let the device driver remain in linux - ie I open and set up
> the device in linux. I only move the part where the packets are written and
> read from the device to RTlinux.
Then it will be not real time any more. For example, if something blocks the
interrupt, the receive of the packet by device driver will be delayed - you
can not get the packet before the standard driver reads it.
Also allocation of skb buffer is non guaranteed to finish within any time
limits - the driver needs to allocate skb for every packet received.
In a similiar way, if you send a packet, the driver might be blocked before
it finishes sending the packet by a higher priority interrupt.
In short - the whole algorithm from receive IRQ to triggerring sending of the
response has to work at RT priority. (I am assuming you want to react to the
packets received in real time - otherwhise the whole story makes no sense).
I would advice you to take a different approach - that is to make a critical
part of wavelan driver real-time and call your routine directly from there.
This means use request_RTirq() instead of request_irq(), use only
pre-allocated memory buffers in the receive-transmit path, do not call
netif_rx, process the data directly in the driver etc. In the kernel space
the only difference between RT and non RT code is whether it can run at a
time when the rest of the kernel thinks that interrupts are disabled.
> If anyone has tackled a similar problem or worked on using a wavelan with
> RTL, your experiences would be of great help.
Is it wavelan 1 or wavelan IEEE ?
What are your timing requirements (the deadline for responding to the
packet)?
Regards,
--
Tomek
--- [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/
