svn commit: r258328 - head/sys/net

Robert Watson rwatson at
Sat Nov 23 10:55:42 UTC 2013

On Wed, 20 Nov 2013, Adrian Chadd wrote:

> We should migrate drivers to use a multi-input method where it's 
> appropriate. It's the same pain as if_transmit() is/was.
> I'd really like to avoid having hacky solutions like mbufs with magic types. 
> If we're going down that path, we should create a correct inline messaging 
> mechanism that includes arbitrary messages in the stream, where some may or 
> may not be mbufs. Magic mbufs just makes me want to tear out my eyes a 
> little.
> So, the reason I'd like to back it out is because we should be doing it via 
> a multi method with some type that represents an mbuf list. If George 
> doesn't mind, I'll add a multi input method, move this stuff into it, and 
> make ether_input just be single frames.

My worry here is that the failure modes for easy oversights and bugs are quite 
subtle ones: mbuf leakage and data corruption.  Our goal should be to shift as 
many as possible of those bugs to compiler-detected events (e.g., due to type 
checking), or where not possible, run-time detected events (e.g., due to 
easily detected non-NULL pointers).  I'm OK with the current change staying in 
the tree for a few weeks on the path there, but I much prefer the world in 
which we use different symbols for different "types".  This is especially 
important if we will have device driver vendors maintaining drivers across 
many versions (which we do): we really don't want a driver using ether_input 
for queue handoff in 11.x to just mysteriously leak mbufs in 10.x.  Instead, 
the driver should fail to compile.


More information about the freebsd-net mailing list