Date: Thu, 21 Nov 2013 01:35:06 +0100 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Adrian Chadd <adrian@freebsd.org> Cc: "src-committers@freebsd.org" <src-committers@freebsd.org>, FreeBSD Net <freebsd-net@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, George Neville-Neil <gnn@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r258328 - head/sys/net Message-ID: <20131121003506.GA30962@onelab2.iet.unipi.it> In-Reply-To: <CAJ-Vmoniz70ziNCickHE8AHVfO95viuk_mO4q8XwD1HH=NxRSQ@mail.gmail.com> References: <201311182258.rAIMwEFd048783@svn.freebsd.org> <CAJ-VmomjQrq39jafTTGQA_EJLSi5j%2BNB=g1sLwCK-KaEfgwrbw@mail.gmail.com> <023E719B-1059-4670-8556-EBAC18A2F007@freebsd.org> <20131121000245.GA30549@onelab2.iet.unipi.it> <CAJ-Vmoniz70ziNCickHE8AHVfO95viuk_mO4q8XwD1HH=NxRSQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131121003506.GA30962>