Jan,
> Better look at the git commits upstream ("gitk v2.6.29..HEAD --
> drivers/net/e100.c", or so), they are more telling than an all-in-one
> diff. But already that diff tells me that upstream gained support for
> yet another adapter variant. Maybe it also received some bug fixes.>
>
I could port this RTNET driver to 2.6.33 however our (test) setup here is
2.6.29.
> That's simple: RTnet, RTDM, and Linux, no single RTAI bit.
>
I am looking at rtdm/drvlib.c and I saw the replacements for rt_task_* and
rt_sem_*.
How do I replace the barrier stuff? (I am coming from a pthreads
environment, hence the APIs I use.)
> Before suggesting that there are proper RTDM abstractions for this: Why
> do you need all this extra threading and IPC at all? And can't that be
> provided via some abstraction by RTnet, *up to the application*? What
> part of the normal RTnet RX/TX path (RX IRQ -> stack manager -> recv
> (application task) / send (application task) -> xmit handler) is
> problematic or insufficient for you?
>
> Well, I did not *represent* that I fully understand the e100 driver. I
tried to keep most of the functionality in the driver in place trusting that
the authors *had a real need* for it [sans power management and WoL]. The
parts I do understand, e.g, LED blink timer, ioctl(), etc I removed. Some
power-managemnt bits are re-used in the normal driver.
I tried to replace Linux delayed-work schemes with RTAI/RTNET equivalents.
(I assumed that the WTD is required to correct chipset bugs -- and I
stumbled into them in the rt_eepro100 driver).
As I am new a to this RT bussiness I implemented a quick IPC scheme that
allows the driver to function as it does in normal Linux.
The RX path is problematic as (again) we intend to drive it from a
FPGA-fired timer IRQ as our IRQ (#11) is shared with USB and sometimes that
wrecks havoc with network timing. Hence using a binary semaphore that is
being kicked by the card IRQ (in the initial port) or by the FPGA IRQ (in
our setup) + a thread.
My question for you is whether it's *correct* to have a Linux timer signal a
RTDM semaphore that is being waited on by a RTDM thread?
Regards,
Vlad
------------------------------------------------------------------------------
_______________________________________________
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
