Hello, Alexander. On Tue, Oct 08, 2013 at 09:48:26AM +0200, Alexander Gordeev wrote: > > If there are many which duplicate the above pattern, it'd probably be > > worthwhile to provide a helper? It's usually a good idea to reduce > > the amount of boilerplate code in drivers. > > I wanted to limit discussion in v1 to as little changes as possible. > I 'planned' those helper(s) for a separate effort if/when the most > important change is accepted and soaked a bit.
The thing is doing it this way generates more churns and noises. Once the simpler ones live behind a wrapper which can be built on the existing interface, we can have both reduced cost and more latitude on the complex cases. > > If we do things this way, it breaks all drivers using this interface > > until they're converted, right? > > Right. And the rest of the series does it. Which breaks bisection which we shouldn't do. > > Also, it probably isn't the best idea > > to flip the behavior like this as this can go completely unnoticed (no > > compiler warning or anything, the same function just behaves > > differently). Maybe it'd be a better idea to introduce a simpler > > interface that most can be converted to? > > Well, an *other* interface is a good idea. What do you mean with the > simpler here? I'm still talking about a simpler wrapper for common cases, which is the important part anyway. Thanks. -- tejun ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk _______________________________________________ E1000-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
