lkml.org 
[lkml]   [2003]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.044 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site