Thanks for your detailed reply. I intended moving the critical parts into
RT just as you have suggested.
The packet transmit routine of the driver will be put in RT and so will the
interrupt handling. So packets will be received and sent in real time. I need
to send packets at periodic intervals of 10ms. I would like to achieve smaller
periods.
My problem right now is an implementation one: When a received packet is to
be handed over to the linux part for processing by higher layers, when a
packet to be sent has to be transferred to the RT part is there any clean way
to access the Fifos from kernel space.
I am using the Lucent Wavelan/PCMCIA 2.4ghz comm. adaptor.
Thank you,
Sugat Jain
Tomasz Motylewski <[EMAIL PROTECTED]> wrote:
> 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/
____________________________________________________________________
Get your own FREE, personal Netscape WebMail account today at
http://webmail.netscape.com.
--- [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/
