NDISwrapper dodges another bullet [LWN.net]

NDISwrapper dodges another bullet

Posted Mar 6, 2008 0:25 UTC (Thu) by jengelh (subscriber, #33263)
In reply to: NDISwrapper dodges another bullet by iabervon
Parent article: NDISwrapper dodges another bullet

>Unless people are distributing systems that are already booted, I don't think anyone could
help but have the end user load the binary driver; I don't think ndiswrapper even supports
linking the driver into it ahead of time.

Consider VMware Suspend Images (*.vmss) — it is possible to distribute booted systems, and as
such, every currently working combination of code.

Well, it may already happen that distributing the Windows driver is bound by some license
already, so you can possibly save on the time to spend about thinking about distributing
linked code.

(Log in to post comments)

NDISwrapper dodges another bullet

Posted Mar 6, 2008 16:07 UTC (Thu) by iabervon (subscriber, #722) [Link]

Doesn't vmware abstract access to network devices anyway? I somehow doubt that a suspend image
containing a Linux kernel using a Windows driver to talk to a physical network device would
actually have any chance of working at all. And running Linux under vmware with the Windows
driver for the vmware simulated network device instead of the Linux driver for it is just
silly.

In order for this particular issue to be relevant, you'd need to distribute a booted system
with a driver loaded for a chipset with only a Windows driver available, which only makes
sense if it's running on physical hardware.

NDISwrapper dodges another bullet

Posted Mar 6, 2008 17:10 UTC (Thu) by jengelh (subscriber, #33263) [Link]

>Doesn't vmware abstract access to network devices anyway?

This is independent of providing a linked variant of ndiswrapper IMHO.

That said, VMware provides virtual HW that behaves like AMD PCnet32 or Intel E1000; so I could
link e1000.drv with ndiswrapper — then what?

Abstraction does not relate to anything. Imagine we had have kexec from/to VMSS someday — then
what?