On 12/12/2014 11:11 PM, Gilles Chanteperdrix wrote:
On Fri, Dec 12, 2014 at 09:12:23PM -0500, Lennart Sorensen wrote:
On Sat, Dec 13, 2014 at 02:03:58AM +0100, Gilles Chanteperdrix wrote:
I understand the need for the "cards" parameter, but...
Is not there another way to solve this issue ? I do not know,
something in /proc or /sys to tell Linux to not load this driver for
that card? I suppose if we tell Linux to not use its driver for some
cards, then later loading the rtnet driver will be used for these
cards? Adding the cards parameter means that the rtnet drivers
diverge from mainline drivers, and so imply a maintenance cost. On
the other hand, maybe that is a cheaper one than trying and solving
the issue globally.
I think the "cards" parameter is a pretty crude solution, too. As you
mentioned, this seems like a more general problem that Linux would already have a
solution for, but my search for another solution turned up empty.
Certainly a well behaved driver would not touch a device already handled
by a linux driver. It should be possible to just issue an unbind request
to the linux driver for the desired device and then a bind request to
the rtnet driver to take over that device.
Thanks for sharing this information. It sounds like that might work.
The problem with the
bind/unbind solution is that the driver that will get all the cards
first depends on the drivers initialization order. With the "cards"
parameter, you do not have this issue.
Maybe one could create a script that would attempt to unbind both the rt and non-rt
drivers (or check to see which one is bound and then unbind it), and then make the
desired "bind" calls. It would be better if the incorrect binding were not
made in the first place, however. I think the ideal solution would be to have a file
that contains device/driver pairs that would keep the kernel from passing the specified
devices to any other drivers. I wonder how hard that would be to implement.
For what it's worth, I have these same issues with 16550 serial port drivers.
The 8250.nr_uarts parameter is helpful, but doesn't cover all use cases.
-Jeff
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
