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.
Robert
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
