Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965052AbVKOW1B (ORCPT ); Tue, 15 Nov 2005 17:27:01 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S965050AbVKOW1B (ORCPT ); Tue, 15 Nov 2005 17:27:01 -0500 Received: from lmcgw.cs.sunysb.edu ([130.245.128.4]:51343 "EHLO smtp.lmc.cs.sunysb.edu") by vger.kernel.org with ESMTP id S965052AbVKOW1A (ORCPT ); Tue, 15 Nov 2005 17:27:00 -0500 Date: Tue, 15 Nov 2005 17:27:10 -0500 From: Giridhar Pemmasani To: Adrian Bunk Cc: linux-kernel@vger.kernel.org Subject: Re: [2.6 patch] i386: always use 4k stacks In-Reply-To: <20051115185543.GI5735@stusta.de> References: <1132020468.27215.25.camel@mindpipe> <20051115032819.GA5620@redhat.com> <43795575.9010904@wolfmountaingroup.com> <20051115050658.GA13660@redhat.com> <43797E05.5090107@wolfmountaingroup.com> <17273.34218.334118.264701@cse.unsw.edu.au> <4379846E.2070006@wolfmountaingroup.com> <20051115141851.18c2c276.grundig@teleline.es> <1132061045.2822.20.camel@laptopd505.fenrus.org> <20051115185543.GI5735@stusta.de> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 MULE XEmacs/21.4 (patch 17) (Jumbo Shrimp) (i386-debian-linux) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20051115222656.8D11816F4D9@smtp.lmc.cs.sunysb.edu> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3360 Lines: 64 On Tue, 15 Nov 2005 19:55:43 +0100, Adrian Bunk said: Adrian> And the fact that it might force people to help with the Adrian> development or at least use open source drivers for their Adrian> hardware instead of binary-only Windows drivers isn't Adrian> exactly a disadvantage for the development of Linux. IMO, this is at best only one side of the coin: Many people that ask for help with ndiswrapper seem to be newbies that have just begun using Linux. Most of these people can't/won't help with development of native drivers. On the other hand, ndiswrapper can be used in reverse engineering. I know of at least two such cases. So thinking ndiswrapper as a scourge that hinders development (I am exaggerating a bit here, but it has been suggested so by certain people more than once on lkml) is not correct. Informed users, especially those that follow lkml, are more interested in helping development of native drivers and would chose to use native drivers if possible. Leaving other end users high and dry without wireless support until such drivers are available is not necessarily helpful for development of open source drivers. In essence, ndiswrapper is for those chipsets that have no open source drivers until one can be developed. This issue raises a concern for me as developer of ndiswrapper. I perceive that some kernel developers have strong opinions against ndiswrapper. I see ndiswrapper as contributing my 2 cents - I have no vested interests in ndiswrapper, although it will be sad to see lot of effort and time put into ndiswrapper go waste. However, I believe there is a need for such a project: There is a company (Linuxant) that sells a product similar to ndiswrapper, ndisulator, which is similar to ndiswrapper, is merged into FreeBSD kernel, and ndiswrapper itself has been downloaded more than half a million times from Sourceforge alone. And not all native drivers support all the features that users need, e.g., WPA, whereas ndiswrapper supports all features provided by vendor for Windows driver. And there are chipsets for which open source drivers may not be available ever since they are rare. And if it takes many months/years to develop a stable open source driver, users need some way of using their hardware until then. And so on. I am not trying to argue in favor of ndiswrapper at the cost of open source drivers, but that there is a genuine need for such a project, at least for now. This is neither a complaint nor a plea; if option to chose 8k stacks is dropped in the kernel, so be it. If I find time to provide support for private 8k stacks within ndiswrapper, I will do that, so that if this patch makes into kernel, users who need some way of using the wireless cards can do so, for now. Adrian> Unconditionally enabling 4k stacks is the only way to Adrian> achieve this. I think this is a bit drastic. As I suggested earlier, making 4k stacks the default may be enough. For example, RedHat already distributes kernels with 4k stacks and I am not sure if you will get lot more cases, considering the popularity of RedHat. -- Giri - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/