So from my experience Dave I think you are being unfair on
Don. Very unfair.
I think my tone was a bit harsh, but I still contend that there needs
to be folks who pick up the slack when he is too busy to respond
expediantly.
For example, the eepro100 high load crashes. He sent what he tought
fixed it, it did not, Linus reverted things again to what works, and
then silence on the matter.
More recently the current issue, 0.99f was bad for a lot of people.
Total silence from him on the matter. Now that I've pointed out the
issue, how long until we see an attempted fix from him? If he is too
busy, should I do it? Should you? Sometimes when this is done he
acts like an animal who has had his territory invaded :-)
I'm just looking for a way that we can get bugs in his drivers fixed
expediantly when he simply does not have time to do it at the moment,
that's all.
On the fast routing code, it is nice that he told you and even told me
his gripes, but what really needs to happen is that he must work out
these issues with ANK who created and can fixup any problems the fast
routing code has.
If you look, ANK has quite a task in front of him if this is to be
genericised as I believe Donald would like it to be. Some drivers
directly DMA into skb's, and we'd like to just push these skb's to the
destination driver with simple ref counts. Other drivers must create
a whole new SKB for each received frame, so these buffers must be
passed and accounted for in a different way. Still other drivers
operate even more differently.
I do agree that the current implementation is a little messy.
Consider it as an example technology, and something we need to fix up.
Later,
David S. Miller
davem@dm.cobaltmicro.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/