[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <45C64807.9030108@tmr.com>
Date: Sun, 04 Feb 2007 15:54:31 -0500
From: Bill Davidsen <davidsen@....com>
To: Jan Engelhardt <jengelh@...ux01.gwdg.de>
CC: David Hollis <dhollis@...ehollis.com>,
Jeff Garzik <jeff@...zik.org>,
Trent Waddington <trent.waddington@...il.com>,
Dave Airlie <airlied@...il.com>,
Roland Dreier <rdreier@...co.com>, Greg KH <greg@...ah.com>,
linux-kernel@...r.kernel.org
Subject: Re: Free Linux Driver Development!
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@....com>
"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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists