Re: Bug#353277: ndiswrapper in main
On Tue, Feb 28, 2006 at 02:36:52PM +0100, Wouter Verhelst wrote:
> The CIPE driver doesn't actually need hardware, since it is an
> encryption layer. As such, I can use it as a test-case for ndiswrapper,
> to find out how the latter works and to actually be able to test whether
> I set it up correctly. If a customer should at one point ask me to help
> them out with setting up ndiswrapper, I can then first experiment on my
> own with the CIPE driver, and then help them out with their non-free
> driver.
In this case I do not want to hire you as a consultant ever, thank you
very much. You should know that Windows gives ~16k stack to network
drivers, while current Linux+ndiswrapper only gives ~6k if you are
lucky, and ~4k if/when the "4K stacks" option becomes the default. So
even if your test case works it _does not_ give any indication that any
other non-free driver will also work. A non-free driver that happens to
use 10k stack will work perfectly on Windows but will not work on the
kernels shipped by Debian at all.
> A kernel hacker might be interested in helping out to hack on
> ndiswrapper itself, but not be very interested in having their laptop
> crash every five minutes by loading experimental versions of the driver.
> An obvious solution would be to use a virtualization environment like
> qemu, but then you can't use a driver that requires specific hardware.
> The fact that CIPE exists, which does not have any hardware
> requirements, can allow you to test stuff without having an unstable
> computing environment for other things.
You are not serious that such a developer would be incapable to locate
the ndiswrapper source if it was in contrib instead of main, are you?
Also, such a developer would be a fool to use the Debian-packaged
version of ndiswrapper instead of the latest upstream snapshot, given
the long time between stable Debian releases.
> Now consider that there is a change in some future version of the
> kernel, which is security-related, and which breaks the kernel API wrt
> network drivers incompatibly.
Unlikely, whoever breaks in-kernel API is responsible for fixing all
in-kernel drivers as well. And IMHO there are more Linux network driver
maintainers than ndiswrapper maintainers, and they are quite capable of
morphing a huge number of drivers at once.
On the other hand, the kernel has already broken compatibility with
ndiswrapper (16k stacks were never part of the official kernel) and
there is effor to break it even more (if you want to look at it from
this angle). Just look up the "4k stack" flamewars in LKML archives.
Fedora already ships it's kernels with 4k stacks.
Please stop these excuses. "ndiswrapper will remain in main because the
sky is blue" is a lot more acceptable reasoning than anything that
popped up in this thread so far. If you _really_ want to help
ndiswrapper, then work on solving the 4k-stack issue; that would help a
_lot_ more than this silly thread.
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
Reply to: