On Wed, Nov 20, 2013 at 04:07:07PM -0800, Adrian Chadd wrote:
> Hi,
>
> We should migrate drivers to use a multi-input method where it's
> appropriate. It's the same pain as if_transmit() is/was.
right, and i think that is very confusing and i'd rather
not replicate the experience.
But what is your plan, have both if_input and if_input_multi ?
And then make the vlan and all similar filters intercept both ?
Because all of the existing options have pros and cons:
1. having both if_input and if_input_multi is visually cleaner
but requires extending ifnet and some convoluted code in the
initialization (same as if_transmit)
2. just if_input with typed mbufs is less clean but has the big
advantage thay you only need to change ether_input() (and equivalent
for other L2 protocols), and it is not error prone
3. having only if_input_multi (even without renaming if_input)
requires you to change all the 100+ drivers.
It seems to me that #2 at least preserves binary compatibility
with driver modules and is easier to backport to other versions
of FreeBSD, this is why i prefer it.
my two cents...
cheers
luigi
> 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.
>
>
>
> -adrian
_______________________________________________
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"
