Jack, you should know by now that we're not Linux. All we care about is that you not break the code that we rely on. I'm still slightly embarrassed when I explain to people that I build if_em as a module because em0 doesn't come up sometimes due to a race condition on initialization, so I need to be able to re-load the driver. We're happy that you're keeping support for Intel's hardware up to date on FreeBSD.
-Kip On 10/29/07, Jack Vogel <[EMAIL PROTECTED]> wrote: > I have an important decision to make and I thought rather than just make > it and spring it on you I'd present the issues and see what opinions were. > > Our newer hardware uses new features that, more and more, require > parallel code paths in the driver. For instance, the 82575 (Zoar) uses > what are called 'advanced descriptors', this means different TX path. > The 7.0 em driver has this support in it, it just uses a function pointer > to handle it. > > When I add in multiqueue/RSS support it will add even more code > that functions this way. > > What the Linux team did was to split the newer code into a standalone > driver, they call it 'igb'. I had originally resisted doing this, but with > the development I have been working on the past month I am starting > to wonder if it might not be best to follow them. > > I see 3 possibilities and I'd like feedback, which would you prefer if > you have a preference and why. > > First, keep the driver as is and just live with multiple code paths > and features, possibly #ifdef'ed as they appear. > > Second, split the driver as Linux has into em and igb. The added > question then is how to split it, Linux made the line the use of > advanced descriptors, so Zoar and after, but I could also see a > case for having everything PCI-E/MSI capable being in the new > driver. > > Third, sort of a half-way approach, split up code but not the > driver, in other words offer different source files that can be > compiled into the driver, so you could have the one big jumbo > driver with all in there, or one that will only work with a subset > of adapters. This one would probably be the most work, because > its a new approach. > > Cheers, > > Jack > _______________________________________________ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
