Messages in this thread | | | Date | Tue, 18 Nov 2003 08:49:24 -0500 (EST) | From | "Richard B. Johnson" <> | Subject | Re: Announce: ndiswrapper |
| |
On Tue, 18 Nov 2003, Maciej Zenczykowski wrote:
> > Pontus Fuchs wrote: > > > Hi, > > > > > > Since some vendors refuses to release specs or even a binary > > > Linux-driver for their WLAN cards I desided to try to solve it myself by > > > making a kernel module that can load Ndis (windows network driver API) > > > drivers. I'm not trying to implement all of the Ndis API but rather > > > implement the functions needed to get these unsupported cards working. > > > > Sounds like a plan! > > Definetely agree - question though, are you loading these drivers into > ring 0 (kernel space)? As far as I know linux only supports ring 0 > (kernel) and 3 (userspace). However this would seem to be the perfect > place to load the binary modules in ring 1 (or even userspace if that was > possible...). I can't say I trust any binary only and/or windows driver > to not make a mess of my kernel :) actually the driver may actually be > errorless - it's just designed for a different operating system and thus > some unexplainable misshaps could easily happen... > > While we're at it, loading binary only modules into ring 1 would probably > also be a good idea for the NV module et al. Although I have no idea how > hard it would be to make ring 1 function (and whether there actually is > any point to doing it in ring 1 instead of ring 3 with iopl/ioperm anyway) > and how big the performance penalty for non-ring 0 would be... > > Cheers, > MaZe. >
Do the NDIS drivers work in 32-bit land? Some kludges do! They were the real-mode DOS driver interface to MS-DOS. Now there is a kludge on top of a kludge called NDIS-6. They also used the Pascal calling convention which screws up 'C' code (you need an assembly wrapper).
They are a waste-of-time. Why would you clone a Microsoft interface for a non-Microsoft Operating System when you can't allow such junk to run inside the kernel anyway.
The problem with third-party binary drivers is not the interface to the kernel. Linux has a public interface, well established and well known. The problem is that any third-party driver can completely f**k up the kernel, either by mistake or by design. So the third-party drivers MUST provide source-code so they can be fixed or made to behave if (read when) problems are found.
Cheers, Dick Johnson Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips). Note 96.31% of all statistics are fiction.
- 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/
| |