> It works very well. They are marked high priority and some can
> be lost happily without problems.
This priority may be not respected, if policy is different of default.
And driver cannot know about this policy, it is too stupid.
And link may be shaped et al.
> Of course it can. I bring the interface up and there is a link at
> the physical layer, but no valid IP path. The wire is up, the IP isnt at
> that point.
I even did not mention IP. I talk about "data". Any data.
Cisco HDLC keepalives are not data. PPP LCP messages are also
not data. And NCP messages are not data. dev_queue_xmit
does not want even hear about them.
> There is no other sane way to do it. It works and it works well. I know
> about the potential problem, but until there is a clean dev_queue_xmit_head()
> function then it will have to stay
dev_queue_xmit_head === hard_start_xmit outside device.
And anything, which driver desires, inside it.
Do you want a proof ad absurdum? OK.
What's about xmitting ethernet setup frames via dev_queue_xmit?
It is almost normal frame. F.e. set_multicast_list prepares
frames and enqueues via dev_queue_xmit. Any problems?
Alexey
-
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/