Re: Free Linux Driver Development!

[Bill Davidsen]

Jan Engelhardt wrote:
> On Jan 31 2007 08:34, David Hollis wrote:
> > Conversely, I've seen many cases of drivers that are developed by the
> > community, but kept out-of-kernel forever due to various reasons.  Some
> > of them are due to the code quality and the developers not accepting the
> > feedback to get the drivers into shape to be 'kernel worthy', sometimes
> > it seems to be a lack of interest from the developers to merge upstream.
> > Maybe because they think they would lose control or something?
>
> Putting the "codingstyle" control aside, often it's because things look
> too hackish. Take ipt_ROUTE as an example. It won't get included, since
> the "proper" way to do it would be using MARK and iproute2. But many users
> don't get that [no criticism here], because ipt_ROUTE is so much easier.
> (Probably because iproute2 and other netlink-using tools, like tc, lack
> thorough documentation.)
Doing it by MARK a tables and rules is an ugly method, and like anything 
with is spread over many places (the mangle table to MARK), then 'rules' 
and 'tables', spreading an action into many places increases the chances 
of getting parts out of sync and having the whole not work as intended. 
And the 'ip' man page defines everything in BNF, which was hot stuff 
when Algol-60 came out (1960) but which is only readable to people who 
use it frequently.

The ipt_ROUTE allows putting all parts of of the action, from defining 
the set of matching packets to specifying the desired result, the 
routing. And if that changes, it need only change in one place.

Making good administration difficult because it fits some pedantic metal 
model is NOT a good way to decide which features to offer in a kernel.

--
Bill Davidsen <davidsen@xxxxxxx>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/