Tue, 03 Nov 2015 00:38:45 +0200 було написано Adrian Chadd <adr...@freebsd.org>:

Actually, this is more annoying than I'd thought. There's a whole
bunch of places where mbufs can change during processing in ath(4) and
yeah, we can't guarantee the original mbuf is available.

I wonder how many other drivers are doing this - stuff like
m_collapse(), m_defrag(), etc. If this is called then the original
mbuf can't be returned upon error.

I have thinked about that few hours ago - there are many ways to fix it:

1) add a guarantee for current m_collapse() / m_defrag() that current
mbuf pointer will not change (like it works in OpenBSD);
2) implement third function with this guarantee (for backward compatibility);
3) pass pointer to mbuf pointer via ic_raw_xmit() / ic_transmit() -
then the caller can change it (that's the way I've seen in other
m_collapse() consumers);
4) move m_defrag() / m_collapse() to the net80211 (to the ieee80211_encap() ?).
This will require an additional parameter, which will limit max number
of segments for device.
... (something else?)
*) leave it 'as is'.

I'm torn as to whether to back out the mbuf API change and have the
driver consume it, or whether we want to go through the pain of fixing

Let's figure this out ASAP.



On 2 November 2015 at 14:35, Adrian Chadd <adr...@freebsd.org> wrote:
Ok, yeah, I think your initial churn of ath(4) for error handling is
way incomplete, and we're going to have to fix this stuff before it
causes lots more issues in -HEAD.

freebsd-wireless@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Reply via email to