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'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
things.

Let's figure this out ASAP.

Thanks,


-adrian


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.
>
>
>
> -a
_______________________________________________
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Reply via email to