<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xml:base="http://www.kerneltrap.org"  xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
 <title>KernelTrap - NDISwrapper</title>
 <link>http://www.kerneltrap.org/taxonomy/term/1209/0</link>
 <description></description>
 <language>en-local</language>
<item>
 <title>Defaulting To 4K Stacks</title>
 <link>http://www.kerneltrap.org/Linux/Defaulting_To_4K_Stacks</link>
 <description>&lt;div class=&quot;taxonomy-images&quot;&gt;&lt;a href=&quot;/news/linux&quot; class=&quot;taxonomy-image-links&quot;&gt;&lt;img src=&quot;http://kerneltrap.org/files/category_pictures/K-Linux.gif&quot; alt=&quot;Linux news&quot; title=&quot;Linux news&quot;  width=&quot;75&quot; height=&quot;75&quot; /&gt;&lt;/a&gt;&lt;/div&gt;&lt;!-- google_ad_section_start --&gt;&lt;p&gt;Andrew Morton &lt;a href=&quot;http://kerneltrap.org/mailarchive/linux-kernel/2008/4/18/1498474&quot;&gt;replied to a commit message&lt;/a&gt; making 4k stacks the default, saying, &quot;&lt;i&gt;this patch will cause kernels to crash.&lt;/i&gt;&quot;  Ingo Molnar replied, &quot;&lt;i&gt;what mainline kernels crash and how will they crash? Fedora and other distros have had 4K stacks enabled for years.&lt;/i&gt;&quot;  He added, &quot;&lt;i&gt;we&#039;ve conducted tens of thousands of bootup tests with all sorts of drivers and kernel options enabled and have yet to see a single crash due to 4K stacks.&lt;/i&gt;&quot;  During the lengthy discussion it was suggested that nfs+xfs+raid kernel configurations, and using ndiswrapper are the most common reasons for overflowing a 4K stack size.&lt;/p&gt;
&lt;p&gt;Andi Kleen questioned the usefulness of 4k stacks, &quot;&lt;i&gt;as far as I can figure out they are not [a worthy goal]. They might have been a worthy goal on crappy 2.4 VMs, but these times are long gone.&lt;/i&gt;&quot;  Arjan van de Ven suggested that though the 2.6 VM is much improved over the 2.4 VM, fragmentation with 8K stacks remains an unsolvable problem,  &quot;&lt;i&gt;it&#039;s basic math; the Linux VM gets to deal with both short and long lasting allocations; no matter how hard you try to get some degree of fragmentation; especially due to the 15:1 acceleration you get due to the lowmem issue.  And before you say &#039;you should use 64 bit on such machines&#039;; I would love it if more people used 64 bit linux. Sadly the adoption rate of that is not very good still.... by far ;(&lt;/i&gt;&quot;  In another email, Arjan listed two advantages to 4K stacks, &quot;&lt;i&gt;1) less memory consumption in the lowmem zone (critical for enterprise use, also good for general performance), and 2) kernel stacks at 8K are one of the most prominent order-1 allocations in the kernel; again with big-memory systems the fragmentation of the lowmem zone is a problem (and the distros that ship 4K stacks went there because of customer complaints)&lt;/i&gt;&quot;.&lt;/p&gt;
&lt;!-- google_ad_section_end --&gt;&lt;p&gt;&lt;a href=&quot;http://www.kerneltrap.org/Linux/Defaulting_To_4K_Stacks&quot; target=&quot;_blank&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <comments>http://www.kerneltrap.org/Linux/Defaulting_To_4K_Stacks#comments</comments>
 <category domain="http://www.kerneltrap.org/4k_stacks">4k stacks</category>
 <category domain="http://www.kerneltrap.org/8k_stacks">8k stacks</category>
 <category domain="http://www.kerneltrap.org/Andi_Kleen">Andi Kleen</category>
 <category domain="http://www.kerneltrap.org/Andrew_Morton">Andrew Morton</category>
 <category domain="http://www.kerneltrap.org/Arjan_van_de_Ven">Arjan van de Ven</category>
 <category domain="http://www.kerneltrap.org/Ingo_Molnar">Ingo Molnar</category>
 <category domain="http://www.kerneltrap.org/Linux">Linux</category>
 <category domain="http://www.kerneltrap.org/merge_window">merge window</category>
 <category domain="http://www.kerneltrap.org/NDISwrapper">NDISwrapper</category>
 <category domain="http://www.kerneltrap.org/news/linux">Linux news</category>
 <pubDate>Wed, 23 Apr 2008 01:42:24 +0000</pubDate>
 <dc:creator>Jeremy</dc:creator>
 <guid isPermaLink="false">16036 at http://www.kerneltrap.org</guid>
</item>
<item>
 <title>Quote: The Question On The Table</title>
 <link>http://www.kerneltrap.org/Quote/The_Question_On_The_Table</link>
 <description>&lt;!-- google_ad_section_start --&gt;&lt;p&gt;&quot;The question on the table is [...] whether we should let ndiswrapper continue using GPLONLY symbols.  Quite frankly, my position on this has always been that the GPLv2 explicitly covers _derived_ works only, and that very obviously a Windows driver isn&#039;t a derived work of the kernel.&lt;/p&gt;
&lt;!-- google_ad_section_end --&gt;&lt;p&gt;&lt;a href=&quot;http://www.kerneltrap.org/Quote/The_Question_On_The_Table&quot; target=&quot;_blank&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <comments>http://www.kerneltrap.org/Quote/The_Question_On_The_Table#comments</comments>
 <category domain="http://www.kerneltrap.org/Linus_Torvalds">Linus Torvalds</category>
 <category domain="http://www.kerneltrap.org/Linux">Linux</category>
 <category domain="http://www.kerneltrap.org/NDISwrapper">NDISwrapper</category>
 <category domain="http://www.kerneltrap.org/quote">quote</category>
 <category domain="http://www.kerneltrap.org/taxonomy/term/1092">Linus Torvalds</category>
 <category domain="http://www.kerneltrap.org/taxonomy/term/1094">linux-kernel</category>
 <pubDate>Wed, 05 Mar 2008 21:33:47 +0000</pubDate>
 <dc:creator>Jeremy</dc:creator>
 <guid isPermaLink="false">15669 at http://www.kerneltrap.org</guid>
</item>
<item>
 <title>NDISwrapper and the GPL</title>
 <link>http://www.kerneltrap.org/Linux/NDISwrapper_and_the_GPL</link>
 <description>&lt;div class=&quot;taxonomy-images&quot;&gt;&lt;a href=&quot;/news/linux&quot; class=&quot;taxonomy-image-links&quot;&gt;&lt;img src=&quot;http://kerneltrap.org/files/category_pictures/K-Linux.gif&quot; alt=&quot;Linux news&quot; title=&quot;Linux news&quot;  width=&quot;75&quot; height=&quot;75&quot; /&gt;&lt;/a&gt;&lt;/div&gt;&lt;!-- google_ad_section_start --&gt;&lt;p&gt;&quot;&lt;i&gt;A change after 2.6.24 broke ndiswrapper by accidentally removing its access to GPL-only symbols,&lt;/i&gt;&quot; noted Pavel Roskin, offering a patch to address the issue.  Linux creator Linus Torvalds was unimpressed, &quot;&lt;i&gt;I&#039;m not seeing why ndiswrapper should be treated separately.  If it loads non-GPL modules, it shouldn&#039;t be able to use GPLONLY symbols.&lt;/i&gt;&quot;  The NDISwrapper project page explains, &quot;&lt;i&gt;many vendors do not release specifications of the hardware or provide a Linux driver for their wireless network cards. This project implements Windows kernel API and NDIS (Network Driver Interface Specification) API within Linux kernel.  A Windows driver for wireless network card is then linked to this implementation so that the driver runs natively, as though it is in Windows, without binary emulation.&lt;/i&gt;&quot;  Due to this, Linus explained:&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;&quot;Ndiswrapper itself is *not* compatible with the GPL. Trying to claim that ndiswrapper somehow itself is GPL&#039;d even though it then loads modules that aren&#039;t is stupid and pointless. Clearly it just re-exports those GPLONLY functions to code that is *not* GPL&#039;d.&quot;&lt;/p&gt;&lt;/blockquote&gt;
&lt;!-- google_ad_section_end --&gt;&lt;p&gt;&lt;a href=&quot;http://www.kerneltrap.org/Linux/NDISwrapper_and_the_GPL&quot; target=&quot;_blank&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <comments>http://www.kerneltrap.org/Linux/NDISwrapper_and_the_GPL#comments</comments>
 <category domain="http://www.kerneltrap.org/GPL">GPL</category>
 <category domain="http://www.kerneltrap.org/Linus_Torvalds">Linus Torvalds</category>
 <category domain="http://www.kerneltrap.org/Linux">Linux</category>
 <category domain="http://www.kerneltrap.org/NDISwrapper">NDISwrapper</category>
 <category domain="http://www.kerneltrap.org/taxonomy/term/261">Windows</category>
 <category domain="http://www.kerneltrap.org/news/linux">Linux news</category>
 <pubDate>Mon, 03 Mar 2008 16:09:40 +0000</pubDate>
 <d