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.
Currently it works fine with my Broadcom 4301 but I would like to get in
touch with people that have similar cards that are willing to do some
testing/hacking.
Visit this page for more info: http://ndiswrapper.sourceforge.net/
Please! I don't want to start a flamewar if this is a good thing to do.
I'm just trying to scratch my own itch and I doubt that this project
changes the way Broadcom treats Linux users.
Pontus Fuchs
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!
Ok, here we go with my intel PRO/2100 (those found in centrino laptops).
The drivers are taken from Acers homepage (I have an Travelmate 800)
[lspci]
02:04.0 Network controller: Intel Corp.: Unknown device 1043 (rev 04)
[lspci -n]
02:04.0 Class 0280: 8086:1043 (rev 04)
[utils/loaddriver 8086 1043 w70n51.sys w70n51.inf]
Calling putdriver ioctl
Unable to put driver (check dmesg for more info): Invalid argument
[dmesg]
Putting driver size 2479104
Unknown symbol: ntoskrnl.exe:strlen
Unknown symbol: ntoskrnl.exe:memcpy
Unknown symbol: ntoskrnl.exe:memset
Unknown symbol: HAL.dll:WRITE_PORT_ULONG
Unknown symbol: HAL.dll:READ_PORT_ULONG
Unknown symbol: NDIS.SYS:NdisResetEvent
Unknown symbol: NDIS.SYS:NdisInitializeString
Unknown symbol: NDIS.SYS:NdisMSleep
Unknown symbol: NDIS.SYS:NdisUnchainBufferAtBack
Unknown symbol: NDIS.SYS:NdisQueryBufferSafe
Unknown symbol: NDIS.SYS:NdisGetFirstBufferFromPacketSafe
Unknown symbol: NDIS.SYS:NdisUnchainBufferAtFront
Unable to prepare driver
--
Christan Axelsson
[email protected]
> 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.
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...
There are development of a userspace driver API I think but I dont know
the state of it nor the speed impacts.
> 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...
See above.
--
Christan Axelsson
[email protected]
Pontus Fuchs wrote:
> Please! I don't want to start a flamewar if this is a good thing to do.
> I'm just trying to scratch my own itch and I doubt that this project
> changes the way Broadcom treats Linux users.
Then help us reverse engineer the driver :)
Jeff
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.
On Tue, 2003-11-18 at 14:49, Richard B. Johnson wrote:
> Linux has a public interface, well established
> and well known.
the syscalls are indeed well established and well known....
inside the kernel it's far less clear and certainly not established
> Pontus Fuchs wrote:
> > Please! I don't want to start a flamewar if this is a good thing to do.
> > I'm just trying to scratch my own itch and I doubt that this project
> > changes the way Broadcom treats Linux users.
>
>
> Then help us reverse engineer the driver :)
>
> Jeff
In a way getting it to run under linux (in an pseudo-ndis-emu box) is part
of getting it reverse engineered - then we set up io-trace and presto we
know precisely what is going on ;)
Speaking of io-trace has anyone actually done this? I'm working on a
strace patch for io-trace'ing of user processes and have come to the
conclusion that this should be at least partially done in kernel-space
(you can't attach/detach to a pid without kernel support, you can io-trace
a program from start to finish in pure userspace, but as soon as you want
to attach to a running Xserver you are basically screwed (although that
can be circumvened), however if you want to detach then you are screwed
totally (unless you like live auto-patching of the traced program)...
I'm thinking of rewriteing the patch into the kernel ptrace mechanism
(i.e. PTRACE_IO_SYSCALL - stop on IO operations or syscalls)
Cheers,
MaZe.
On Tue, 18 Nov 2003, Jeff Garzik wrote:
> Pontus Fuchs wrote:
> > Please! I don't want to start a flamewar if this is a good thing to do.
> > I'm just trying to scratch my own itch and I doubt that this project
> > changes the way Broadcom treats Linux users.
>
>
> Then help us reverse engineer the driver :)
>
> Jeff
Yes! Entirely! The BIG advantage of the NDIS-6 driver is
the established interface makes it possible to readily
reverse-engineer it, i.e., find out how it works. Many
of the network drivers use the same hardware core (ne).
It's the extra stuff like the transciever interface that
the NDIS drivers will expose.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
On Tue, 18 Nov 2003, Jeff Garzik wrote:
> Pontus Fuchs wrote:
> > Please! I don't want to start a flamewar if this is a good thing to do.
> > I'm just trying to scratch my own itch and I doubt that this project
> > changes the way Broadcom treats Linux users.
>
>
> Then help us reverse engineer the driver :)
They're already doing it (non-free) :)
http://www.linuxant.com/driverloader/
- Davide
On Tue, 2003-11-18 15:14:01 +0100, Maciej Zenczykowski <[email protected]>
wrote in message <[email protected]>:
> > Pontus Fuchs wrote:
> Speaking of io-trace has anyone actually done this? I'm working on a
It's actually not all that simple. Some CPUs do have direct inb/outb
instructions that are not syscalls. So you either have to single-step
all the program and look at it's execution path, or you'd run it as a
notmal user and handle the privilege penetration then luser starts
inb'ing:) A coworker of me has done that with a DOS driver, doing such
IO tracing for the dosemu it was running it.
Maybe he cares to explain it in detail...
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg
fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak!
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
> > Speaking of io-trace has anyone actually done this? I'm working on a
>
> It's actually not all that simple. Some CPUs do have direct inb/outb
> instructions that are not syscalls. So you either have to single-step
> all the program and look at it's execution path, or you'd run it as a
> notmal user and handle the privilege penetration then luser starts
> inb'ing:) A coworker of me has done that with a DOS driver, doing such
> IO tracing for the dosemu it was running it.
>
> Maybe he cares to explain it in detail...
>
> MfG, JBG
Well I have a working patch for linux x86 strace 4.5 (mostly needs
cleanup) which implements IO-trace for non-mmaped IO by causing protection
violations on IO instructions. Normally you'd call ioperm/iopl to get at
the hardware this is intercepted, noted on the side and _not_ passed to
the kernel. All IO accesses from now on cause SIGSEGV's - which I procede
to printf and emulate.
I'm still not decided on whether this should be done entirely in
user-space (there are issues...) or partially or even mostly in kernel.
I'm attaching a patch for strace 4.5 (from sourceforge), you'll need to
patch and then likely run aclocal and automake before configure and make.
It currently only works for x86 linux non-string IO instructions for plain
non-segmented 32bit code (which is probably 99% of x86 IO not covered by
dosemu). Attach/detach don't work (fully), so you'll want to strace -I a
program from the very beginning :) I've run SVGATextMode through it and
it works, haven't tried it but the Xserver would likely work as well
(although that would probably require far more disk space in tmp then I
have :)). If you're strace'ing IO which access the video card it is
probably smart to redirect stderr to a file to keep the kernel from
accessing the video card at the same time (locking during strace is
impossible).
Any comments? Feedback and ideas are welcome...
Cheers,
MaZe.
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.
>
> Currently it works fine with my Broadcom 4301 but I would like to get in
> touch with people that have similar cards that are willing to do some
> testing/hacking.
Wow, works for me, Broadcom 94306. [Well, I do not have second wifi to
test right now, but module loads, I can iwconfig it etc.] I'd add this
to the docs:
Index: README
===================================================================
RCS file: /cvsroot/ndiswrapper/ndiswrapper/README,v
retrieving revision 1.1
diff -u -u -r1.1 README
--- README 17 Nov 2003 13:23:36 -0000 1.1
+++ README 18 Nov 2003 22:19:22 -0000
@@ -4,8 +4,11 @@
1. Compile the driver
---------------------
* You need kernel 2.6.0-test8 or higher!
-* Make sure your kernel complied without framepointer and Sleep-inside-spinlock debugging
- See the kernel hacking menu
+* Make sure your kernel complied without framepointer
+ (CONFIG_FRAME_POINTER unset) and Sleep-inside-spinlock
+ debugging (CONFIG_DEBUG_SPINLOCK unset). (See the kernel hacking menu)
+* do make modules_install
+* make sure you are not cross-compiling
> cd driver
> make
And perhaps this script gets usefull? [Fancy version might download
that package using wget then unzip it ;-).]
Pavel
#!/bin/bash
if zcat /proc/config.gz | grep CONFIG_FRAME_POINTER=y; then
echo Turn off CONFIG_FRAME_POINTER
fi
if zcat /proc/config.gz | grep CONFIG_DEBUG_SPINLOCK=y; then
echo Turn off CONFIG_DEBUG_SPINLOCK
fi
(
cd driver
make
)
(
cd utils
make
)
if lspci | grep "Broadcom Corporation BCM94306"; then
echo "This one should work, good."
insmod driver/ndiswrapper.ko
echo "Get R65194.EXE and unpack it here."
utils/loaddriver 14e4 4320 R65194/TMSetup/bcmwl5.sys R65194/TMSetup/bcmwl5.inf
fi
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
Jeff Garzik wrote :
>
> Pontus Fuchs wrote:
> > Please! I don't want to start a flamewar if this is a good thing to do.
> > I'm just trying to scratch my own itch and I doubt that this project
> > changes the way Broadcom treats Linux users.
>
>
> Then help us reverse engineer the driver :)
>
> Jeff
Even better :
1) go to the Wireless LAN Howto
2) find a card are supported under Linux that suit your needs
3) buy this card
I don't see the point of giving our money to vendors that
don't care about us when there are vendors making a real effort toward
us.
Regards,
Jean
On Wed, Nov 19, 2003 at 10:26:59PM -0500, Jeff Garzik wrote:
> Jean Tourrilhes wrote:
> >Jeff Garzik wrote :
> >>Then help us reverse engineer the driver :)
>
> >
> > Even better :
> > 1) go to the Wireless LAN Howto
> > 2) find a card are supported under Linux that suit your needs
> > 3) buy this card
> > I don't see the point of giving our money to vendors that
> >don't care about us when there are vendors making a real effort toward
> >us.
>
>
> Unfortunately that leaves users without support for any recent wireless
> hardware.
Excuse me ? Have you looked at the Howto lately ? There is
only Broadcom and Intel which are not supported, which leaves plenty
of choice (including many 802.11g and 802.11a cards).
> It gets more and more difficult to even find Linux-supported
> wireless at Fry's and other retail locations...
If you are careful, you can even buy at Fry's. I bought
recently some Microsoft cards ;-)
> Jeff
Jean
Jean Tourrilhes wrote:
> Jeff Garzik wrote :
>>Then help us reverse engineer the driver :)
>
> Even better :
> 1) go to the Wireless LAN Howto
> 2) find a card are supported under Linux that suit your needs
> 3) buy this card
> I don't see the point of giving our money to vendors that
> don't care about us when there are vendors making a real effort toward
> us.
Unfortunately that leaves users without support for any recent wireless
hardware. It gets more and more difficult to even find Linux-supported
wireless at Fry's and other retail locations...
Jeff
Jean Tourrilhes wrote:
>> Even better :
>> 1) go to the Wireless LAN Howto
>> 2) find a card are supported under Linux that suit your needs
>> 3) buy this card
>> I don't see the point of giving our money to vendors that
>> don't care about us when there are vendors making a real effort toward
>> us.
On Wed, Nov 19, 2003 at 10:26:59PM -0500, Jeff Garzik wrote:
> Unfortunately that leaves users without support for any recent wireless
> hardware. It gets more and more difficult to even find Linux-supported
> wireless at Fry's and other retail locations...
And what good would it be to have an entire driver subsystem populated
by binary-only drivers? That's not part of Linux, that's "welcome to
nvidia hell" for that subsystem too, and not just graphics cards.
I say we should go the precise opposite direction and take a hard line
stance against binary drivers, lest we find there are none left we even
have source to and are bombarded with unfixable bugreports.
No, it's not my call to make, but basically, I don't see many benefits
left. The additional drivers we got out of this were highly version-
dependent, extremely fragile, and have been generating massive numbers
of bugreports nonstop on a daily basis since their inception.
We'd lose a few things, like vmware, but it's not worth the threat of
vendors migrating en masse to NDIS/etc. emulation layers and dropping
all spec publication and source drivers, leaving us entirely at the
mercy of BBB's (Buggy Binary Blobs) to do any io whatsoever.
Seriously, the binary-only business has been doing us a disservice, and
is threatening to do worse.
-- wli
William Lee Irwin III wrote:
>Jean Tourrilhes wrote:
>
>>> Even better :
>>> 1) go to the Wireless LAN Howto
>>> 2) find a card are supported under Linux that suit your needs
>>> 3) buy this card
>>> I don't see the point of giving our money to vendors that
>>>don't care about us when there are vendors making a real effort toward
>>>us.
>>>
>
>On Wed, Nov 19, 2003 at 10:26:59PM -0500, Jeff Garzik wrote:
>
>>Unfortunately that leaves users without support for any recent wireless
>>hardware. It gets more and more difficult to even find Linux-supported
>>wireless at Fry's and other retail locations...
>>
>
>And what good would it be to have an entire driver subsystem populated
>by binary-only drivers? That's not part of Linux, that's "welcome to
>nvidia hell" for that subsystem too, and not just graphics cards.
>
>I say we should go the precise opposite direction and take a hard line
>stance against binary drivers, lest we find there are none left we even
>have source to and are bombarded with unfixable bugreports.
>
>No, it's not my call to make, but basically, I don't see many benefits
>left. The additional drivers we got out of this were highly version-
>dependent, extremely fragile, and have been generating massive numbers
>of bugreports nonstop on a daily basis since their inception.
>
>We'd lose a few things, like vmware, but it's not worth the threat of
>vendors migrating en masse to NDIS/etc. emulation layers and dropping
>all spec publication and source drivers, leaving us entirely at the
>mercy of BBB's (Buggy Binary Blobs) to do any io whatsoever.
>
>Seriously, the binary-only business has been doing us a disservice, and
>is threatening to do worse.
>
You have to admit its good for end users though. And indirectly, what
is good for them is good for us. Take the nvidia example: end users get
either a binary driver or nothing. If we were somehow able to stop
nvidia from distributing their binary driver, they would say "OK".
I don't advocate making it easy to do non native drivers of course.
On Thursday November 20, [email protected] wrote:
>
> You have to admit its good for end users though. And indirectly, what
> is good for them is good for us. Take the nvidia example: end users get
> either a binary driver or nothing. If we were somehow able to stop
> nvidia from distributing their binary driver, they would say "OK".
Is it good for end users? It allows them to buy a computer with an
nvidia graphics controller because "NVidia supply drivers", and then
discover that support is only as good as NVidia are willing to make
it. I'm still waiting for some sort of power management support for
the nvidia controller in my notebook. If the driver and the specs
were open, I could possibly do it myself. On the other hand if there
were no NVidia drivers, I never would have made the (arguable) mistake
of buying this notebook.
Ofcourse we cannot and should not stop people from providing the
option of binary only drivers, but I'm not convinced that we should
acknowlege that people who provide binary-only drivers are doing a
useful service for anyone but themselves.
(fortuantely I could buy an alternate wireless card which does have
open-source drives. It's not so easy to buy an alternate video
controler for a notebook - yet).
NeilBrown
William Lee Irwin III wrote:
>> We'd lose a few things, like vmware, but it's not worth the threat of
>> vendors migrating en masse to NDIS/etc. emulation layers and dropping
>> all spec publication and source drivers, leaving us entirely at the
>> mercy of BBB's (Buggy Binary Blobs) to do any io whatsoever.
>> Seriously, the binary-only business has been doing us a disservice, and
>> is threatening to do worse.
On Thu, Nov 20, 2003 at 03:16:46PM +1100, Nick Piggin wrote:
> You have to admit its good for end users though. And indirectly, what
> is good for them is good for us. Take the nvidia example: end users get
> either a binary driver or nothing. If we were somehow able to stop
> nvidia from distributing their binary driver, they would say "OK".
> I don't advocate making it easy to do non native drivers of course.
I'm not convinced it is good for end users. They _think_ they're
getting something that's supported by Linux, but are instead getting
something highly problematic that ties them to specific kernel
versions and cuts off most, if not all, avenues of support available.
It's very much a second-class flavor of open source. They dare not
change the kernel version lest the binary-only trainwreck explode.
They dare not run with the whiz-bang patches going around they're
interested in lest the binary-only trainwreck explode. It may oops
in mainline, and all they can do is wait for a tech support line to
answer. Well, they're a little better than that, they have hackers
out and about, but you're still stuck waiting for a specific small
set of individuals and lose all of the "many eyes" advantages.
-- wli
Neil Brown wrote:
>On Thursday November 20, [email protected] wrote:
>
>>You have to admit its good for end users though. And indirectly, what
>>is good for them is good for us. Take the nvidia example: end users get
>>either a binary driver or nothing. If we were somehow able to stop
>>nvidia from distributing their binary driver, they would say "OK".
>>
>
>Is it good for end users? It allows them to buy a computer with an
>nvidia graphics controller because "NVidia supply drivers", and then
>discover that support is only as good as NVidia are willing to make
>it. I'm still waiting for some sort of power management support for
>the nvidia controller in my notebook. If the driver and the specs
>were open, I could possibly do it myself. On the other hand if there
>were no NVidia drivers, I never would have made the (arguable) mistake
>of buying this notebook.
>
I'm all for open specs, but in reality that doesn't always happen.
(out of interest, are there any OS 3d drivers for any current cards?)
I know what you mean, but I would find nvidia more at fault for not
providing power management than no OS drivers.
>
>Ofcourse we cannot and should not stop people from providing the
>option of binary only drivers, but I'm not convinced that we should
>acknowlege that people who provide binary-only drivers are doing a
>useful service for anyone but themselves.
>
No I wouldn't say that, I meant the Linux Kernel is doing the end users
a favour by allowing binary modules.
William Lee Irwin III wrote:
>William Lee Irwin III wrote:
>
>>>We'd lose a few things, like vmware, but it's not worth the threat of
>>>vendors migrating en masse to NDIS/etc. emulation layers and dropping
>>>all spec publication and source drivers, leaving us entirely at the
>>>mercy of BBB's (Buggy Binary Blobs) to do any io whatsoever.
>>>Seriously, the binary-only business has been doing us a disservice, and
>>>is threatening to do worse.
>>>
>
>On Thu, Nov 20, 2003 at 03:16:46PM +1100, Nick Piggin wrote:
>
>>You have to admit its good for end users though. And indirectly, what
>>is good for them is good for us. Take the nvidia example: end users get
>>either a binary driver or nothing. If we were somehow able to stop
>>nvidia from distributing their binary driver, they would say "OK".
>>I don't advocate making it easy to do non native drivers of course.
>>
>
>I'm not convinced it is good for end users. They _think_ they're
>getting something that's supported by Linux, but are instead getting
>something highly problematic that ties them to specific kernel
>versions and cuts off most, if not all, avenues of support available.
>
Well what they get is hardware accelerated 3d graphics under Linux.
If they didn't need 3d, they can use the open source drivers.
If someone downloads and installs the drivers themselves, they should
know enough to contact nvidia for support (I think nvidia have been
pretty good). Others will contact their ditro support.
There might be a problem where they percieve that Linux is unstable
while it is actually binary drivers.
>
>It's very much a second-class flavor of open source. They dare not
>change the kernel version lest the binary-only trainwreck explode.
>They dare not run with the whiz-bang patches going around they're
>interested in lest the binary-only trainwreck explode. It may oops
>in mainline, and all they can do is wait for a tech support line to
>answer. Well, they're a little better than that, they have hackers
>out and about, but you're still stuck waiting for a specific small
>set of individuals and lose all of the "many eyes" advantages.
>
I must say that I've been using the same nvidia drivers on my desktop
system for maybe a year, and never had a crash including going through
countless versions of 2.5/6. True you need to recompile the intermediate
layer, but then, nobody who knows less than me will know or care about
kernel versions. Their distro will upgrade kernel+drivers if needed, and
presumably the distro has done some sort of testing / QA.
Randy.Dunlap wrote:
>On Thu, 20 Nov 2003 15:49:05 +1100 Nick Piggin <[email protected]> wrote:
>
>| Neil Brown wrote:
>|
>
>| >
>| >Ofcourse we cannot and should not stop people from providing the
>| >option of binary only drivers, but I'm not convinced that we should
>| >acknowlege that people who provide binary-only drivers are doing a
>| >useful service for anyone but themselves.
>| >
>|
>| No I wouldn't say that, I meant the Linux Kernel is doing the end users
>| a favour by allowing binary modules.
>
>that's questionable since we can't support them (i.e. fix bugs/problems
>with them).
>
We don't, nvidia does (directly or through a distro).
We provide choice, right?
On Thu, 20 Nov 2003 15:49:05 +1100 Nick Piggin <[email protected]> wrote:
| Neil Brown wrote:
|
| >On Thursday November 20, [email protected] wrote:
| >
| >>You have to admit its good for end users though. And indirectly, what
| >>is good for them is good for us. Take the nvidia example: end users get
| >>either a binary driver or nothing. If we were somehow able to stop
| >>nvidia from distributing their binary driver, they would say "OK".
| >>
| >
| >Is it good for end users? It allows them to buy a computer with an
| >nvidia graphics controller because "NVidia supply drivers", and then
| >discover that support is only as good as NVidia are willing to make
| >it. I'm still waiting for some sort of power management support for
| >the nvidia controller in my notebook. If the driver and the specs
| >were open, I could possibly do it myself. On the other hand if there
| >were no NVidia drivers, I never would have made the (arguable) mistake
| >of buying this notebook.
| >
|
| I'm all for open specs, but in reality that doesn't always happen.
| (out of interest, are there any OS 3d drivers for any current cards?)
|
| I know what you mean, but I would find nvidia more at fault for not
| providing power management than no OS drivers.
|
| >
| >Ofcourse we cannot and should not stop people from providing the
| >option of binary only drivers, but I'm not convinced that we should
| >acknowlege that people who provide binary-only drivers are doing a
| >useful service for anyone but themselves.
| >
|
| No I wouldn't say that, I meant the Linux Kernel is doing the end users
| a favour by allowing binary modules.
that's questionable since we can't support them (i.e. fix bugs/problems
with them).
--
~Randy
On Wed, 19 Nov 2003 20:38:48 PST, William Lee Irwin III said:
> It's very much a second-class flavor of open source. They dare not
> change the kernel version lest the binary-only trainwreck explode.
> They dare not run with the whiz-bang patches going around they're
> interested in lest the binary-only trainwreck explode. It may oops
> in mainline, and all they can do is wait for a tech support line to
> answer. Well, they're a little better than that, they have hackers
> out and about, but you're still stuck waiting for a specific small
> set of individuals and lose all of the "many eyes" advantages.
On the flip side, if I go back as far as 2.5.4<mumble>, I've had a lot more
days where the open-source drivers for my Xircom ethernet/modem card were
broken than days where my binary NVidia driver was broken. Also, the Xircom
has been the cause of a lot more "hang before even single user mode" problems,
and several times the Xircom didn't start working again until there was a
complete overhaul of the Cardbus support, while there's not been that much
activity on the NVidia patch on http://www.minion.de.
It's certainly seemed like I've ended up "stuck waiting for a specific
small set of individuals" when the Cardbus support has broken (not to
slight them, they're all great guys and do support the stuff) - how many
people on this list *really* understand that code? And it's not just
the Cardbus stuff - there's a LOT of stuff in the kernel that's only
really understood by a very small number of people.
William Lee Irwin III wrote:
>> I'm not convinced it is good for end users. They _think_ they're
>> getting something that's supported by Linux, but are instead getting
>> something highly problematic that ties them to specific kernel
>> versions and cuts off most, if not all, avenues of support available.
On Thu, Nov 20, 2003 at 03:59:46PM +1100, Nick Piggin wrote:
> Well what they get is hardware accelerated 3d graphics under Linux.
> If they didn't need 3d, they can use the open source drivers.
> If someone downloads and installs the drivers themselves, they should
> know enough to contact nvidia for support (I think nvidia have been
> pretty good). Others will contact their ditro support.
"cuts off most, if not all, avenues of support available" == any and
all problems with the things around are untraceable. We won't touch
tainted bugreports and rightly so. And nvidia isn't supporting the
whole kernel.
On Thu, Nov 20, 2003 at 03:59:46PM +1100, Nick Piggin wrote:
> There might be a problem where they percieve that Linux is unstable
> while it is actually binary drivers.
Yes, that's one I'm very concerned about.
William Lee Irwin III wrote:
>> It's very much a second-class flavor of open source. They dare not
>> change the kernel version lest the binary-only trainwreck explode.
>> They dare not run with the whiz-bang patches going around they're
>> interested in lest the binary-only trainwreck explode. It may oops
>> in mainline, and all they can do is wait for a tech support line to
>> answer. Well, they're a little better than that, they have hackers
>> out and about, but you're still stuck waiting for a specific small
>> set of individuals and lose all of the "many eyes" advantages.
On Thu, Nov 20, 2003 at 03:59:46PM +1100, Nick Piggin wrote:
> I must say that I've been using the same nvidia drivers on my desktop
> system for maybe a year, and never had a crash including going through
> countless versions of 2.5/6. True you need to recompile the intermediate
> layer, but then, nobody who knows less than me will know or care about
> kernel versions. Their distro will upgrade kernel+drivers if needed, and
> presumably the distro has done some sort of testing / QA.
They're rather sensitive to VM changes, and I've had people with
significantly less know-how than either of us come back after trying VM
patches in combination with nvidia stuff report things ranging from
oopsen, to reboots, to fs corruption. The insulation layers are only
partially effective at best. And end-users are fiddling with whiz bang
patches for their kernels and upgrading versions by means other than
distros. Heck, the distros aren't even shipping 2.6, and they're
running 2.6 plus patches.
And besides, nvidia is really just the most commonly reported issue due
to the hordes of end users, there are many other offenders on this
front (e.g. certain FC drivers, and apparently some wireless drivers).
-- wli
William Lee Irwin III wrote:
>William Lee Irwin III wrote:
>
>>>I'm not convinced it is good for end users. They _think_ they're
>>>getting something that's supported by Linux, but are instead getting
>>>something highly problematic that ties them to specific kernel
>>>versions and cuts off most, if not all, avenues of support available.
>>>
>
>On Thu, Nov 20, 2003 at 03:59:46PM +1100, Nick Piggin wrote:
>
>>Well what they get is hardware accelerated 3d graphics under Linux.
>>If they didn't need 3d, they can use the open source drivers.
>>If someone downloads and installs the drivers themselves, they should
>>know enough to contact nvidia for support (I think nvidia have been
>>pretty good). Others will contact their ditro support.
>>
>
>"cuts off most, if not all, avenues of support available" == any and
>all problems with the things around are untraceable. We won't touch
>tainted bugreports and rightly so. And nvidia isn't supporting the
>whole kernel.
>
>
I guess they're tracable for nvidia. I'm not aware of how nvidia
Linux development works. I assumed from the lack of bug reports that
they had done something about it. I concede that bad support from
a vendor might cause a bad perception of Linux.
>
>On Thu, Nov 20, 2003 at 03:59:46PM +1100, Nick Piggin wrote:
>
>>There might be a problem where they percieve that Linux is unstable
>>while it is actually binary drivers.
>>
>
>Yes, that's one I'm very concerned about.
>
Bad problem.
>
>
>William Lee Irwin III wrote:
>
>>>It's very much a second-class flavor of open source. They dare not
>>>change the kernel version lest the binary-only trainwreck explode.
>>>They dare not run with the whiz-bang patches going around they're
>>>interested in lest the binary-only trainwreck explode. It may oops
>>>in mainline, and all they can do is wait for a tech support line to
>>>answer. Well, they're a little better than that, they have hackers
>>>out and about, but you're still stuck waiting for a specific small
>>>set of individuals and lose all of the "many eyes" advantages.
>>>
>
>On Thu, Nov 20, 2003 at 03:59:46PM +1100, Nick Piggin wrote:
>
>>I must say that I've been using the same nvidia drivers on my desktop
>>system for maybe a year, and never had a crash including going through
>>countless versions of 2.5/6. True you need to recompile the intermediate
>>layer, but then, nobody who knows less than me will know or care about
>>kernel versions. Their distro will upgrade kernel+drivers if needed, and
>>presumably the distro has done some sort of testing / QA.
>>
>
>They're rather sensitive to VM changes, and I've had people with
>significantly less know-how than either of us come back after trying VM
>patches in combination with nvidia stuff report things ranging from
>oopsen, to reboots, to fs corruption. The insulation layers are only
>partially effective at best. And end-users are fiddling with whiz bang
>patches for their kernels and upgrading versions by means other than
>distros. Heck, the distros aren't even shipping 2.6, and they're
>running 2.6 plus patches.
>
I didn't mean that in an elitist way (you shouldn't be compiling
kernels unless you are taller than the sign) - I just mean the knowledge
required to recompile the kernel and nvidia drivers. And the people
with that know how should generally know that the binary modules
can be unstable. Again I concede this won't always be the case.
On Thu, Nov 20, 2003 at 03:49:05PM +1100, Nick Piggin wrote:
> I'm all for open specs, but in reality that doesn't always happen.
> (out of interest, are there any OS 3d drivers for any current cards?)
> I know what you mean, but I would find nvidia more at fault for not
> providing power management than no OS drivers.
The rationales for closed specs are bogus, so I have zero sympathy.
It's generally a braindead encoding for commands to carry out well-
understood operations. There is nothing to hide, except, of course,
the ability to use the hardware.
-- wli
William Lee Irwin III wrote:
> Jean Tourrilhes wrote:
>
>>> Even better :
>>> 1) go to the Wireless LAN Howto
>>> 2) find a card are supported under Linux that suit your needs
>>> 3) buy this card
>>> I don't see the point of giving our money to vendors that
>>>don't care about us when there are vendors making a real effort toward
>>>us.
>
>
> On Wed, Nov 19, 2003 at 10:26:59PM -0500, Jeff Garzik wrote:
>
>>Unfortunately that leaves users without support for any recent wireless
>>hardware. It gets more and more difficult to even find Linux-supported
>>wireless at Fry's and other retail locations...
>
>
> And what good would it be to have an entire driver subsystem populated
> by binary-only drivers? That's not part of Linux, that's "welcome to
> nvidia hell" for that subsystem too, and not just graphics cards.
>
> I say we should go the precise opposite direction and take a hard line
> stance against binary drivers, lest we find there are none left we even
> have source to and are bombarded with unfixable bugreports.
Who brought binary drivers into this? And when I have ever advocated
binary drivers?
ndiswrapper has one use IMHO (which was pointed out me in this
thread)... to assist in reverse engineering.
Jeff
William Lee Irwin III wrote:
>> And what good would it be to have an entire driver subsystem populated
>> by binary-only drivers? That's not part of Linux, that's "welcome to
>> nvidia hell" for that subsystem too, and not just graphics cards.
>> I say we should go the precise opposite direction and take a hard line
>> stance against binary drivers, lest we find there are none left we even
>> have source to and are bombarded with unfixable bugreports.
On Thu, Nov 20, 2003 at 12:25:10AM -0500, Jeff Garzik wrote:
> Who brought binary drivers into this? And when I have ever advocated
> binary drivers?
> ndiswrapper has one use IMHO (which was pointed out me in this
> thread)... to assist in reverse engineering.
Hmm, maybe I've gotten the whole purpose of the thread wrong. =(
-- wli
William Lee Irwin III wrote:
>On Thu, Nov 20, 2003 at 03:49:05PM +1100, Nick Piggin wrote:
>
>>I'm all for open specs, but in reality that doesn't always happen.
>>(out of interest, are there any OS 3d drivers for any current cards?)
>>I know what you mean, but I would find nvidia more at fault for not
>>providing power management than no OS drivers.
>>
>
>The rationales for closed specs are bogus, so I have zero sympathy.
>It's generally a braindead encoding for commands to carry out well-
>understood operations. There is nothing to hide, except, of course,
>the ability to use the hardware.
>
Well OK, but whether the manufacturers are bad or good, there will be
some that aren't going to release specs or open source drivers. I think
it is *mostly* positive that the Linux kernel allows them to support
Linux though binary drivers.
Note, I'm talking about the kernel. We are all agreed that closed specs
are a bad move by manufacturers.
William Lee Irwin III wrote:
> On Thu, Nov 20, 2003 at 03:49:05PM +1100, Nick Piggin wrote:
>
>>I'm all for open specs, but in reality that doesn't always happen.
>>(out of interest, are there any OS 3d drivers for any current cards?)
>>I know what you mean, but I would find nvidia more at fault for not
>>providing power management than no OS drivers.
>
>
> The rationales for closed specs are bogus, so I have zero sympathy.
Definitely agreed.
When I am forced to sign NDAs to get hardware specs, the hardware IP
"revealed" is inevitably something that some other company has done
before, and done better. NDAs and closed specs are IMO only used by
vendors to save face, when their hardware design is stupid, and their
errata innumerable.
Jeff
> We don't, nvidia does (directly or through a distro).
> We provide choice, right?
To x86 users only :(
Ben.
On Thu, Nov 20, 2003 at 03:16:46PM +1100, Nick Piggin wrote:
>
>
> William Lee Irwin III wrote:
>
> >Jean Tourrilhes wrote:
> >
> >>> Even better :
> >>> 1) go to the Wireless LAN Howto
> >>> 2) find a card are supported under Linux that suit your needs
> >>> 3) buy this card
> >>> I don't see the point of giving our money to vendors that
> >>>don't care about us when there are vendors making a real effort toward
> >>>us.
> >>>
> >
> >On Wed, Nov 19, 2003 at 10:26:59PM -0500, Jeff Garzik wrote:
> >
> >>Unfortunately that leaves users without support for any recent wireless
> >>hardware. It gets more and more difficult to even find Linux-supported
> >>wireless at Fry's and other retail locations...
> >>
> >
> >And what good would it be to have an entire driver subsystem populated
> >by binary-only drivers? That's not part of Linux, that's "welcome to
> >nvidia hell" for that subsystem too, and not just graphics cards.
> >
> >I say we should go the precise opposite direction and take a hard line
> >stance against binary drivers, lest we find there are none left we even
> >have source to and are bombarded with unfixable bugreports.
> >
> >No, it's not my call to make, but basically, I don't see many benefits
> >left. The additional drivers we got out of this were highly version-
> >dependent, extremely fragile, and have been generating massive numbers
> >of bugreports nonstop on a daily basis since their inception.
> >
> >We'd lose a few things, like vmware, but it's not worth the threat of
> >vendors migrating en masse to NDIS/etc. emulation layers and dropping
> >all spec publication and source drivers, leaving us entirely at the
> >mercy of BBB's (Buggy Binary Blobs) to do any io whatsoever.
> >
> >Seriously, the binary-only business has been doing us a disservice, and
> >is threatening to do worse.
> >
>
> You have to admit its good for end users though. And indirectly, what
> is good for them is good for us.
No. It is bad for the end users - they get sold a bill of goods. And
it is bad for developers. And it is bad for developers as users. And
it's hopelessly short-sighted as pragmatism often is.
Look, there's basically one thing that has ever historically enabled
developers to get specs for writing decent Linux drivers, and that's
demand from Linux users. If companies are presented with alternatives
that pointy haired folks prefer like binary-only drivers or running
their one and only Windows driver on an emulation layer, which are
they going to choose and where are they going to tell users to stick
their penguin? We'll be in worse shape than we were when no one had
ever heard of Linux.
Scenario to think about: an NDIS driver layer ends up getting firmed
up and debugged and when the next generation of wireless appears,
basically all vendors go the easy route and only ship NDIS drivers, no
specs, and buggy as usual. Then they say hey, this worked out well,
might as well do this with gigabit. Meanwhile, hardware's changing so
quickly that by the time we manage to reverse-engineer any of this
stuff (provided the legal climate allows it), it's already off the
shelves. Two to three years from now, it's impossible to build a
decent server or laptop that doesn't have bug-ridden, untested, low
performance network drivers and all the reputation Linux has for being
a good network OS goes down the tubes. It's safe to assume that
latency and stability will go all to hell as well.
An open operating system without open drivers is pointless and if we
don't do something about all this binary crap soon, the above scenario
-will- play out. Expect SCSI and perhaps sound to follow soon
afterwards. And graphics cards and modems are obviously half-way there
already.
Personally, I think it's time to do some sort of trademark enforcement
or something so that companies can't get away with slapping penguins
on devices that only work with 2.2.14 Red Hat kernels.
--
Matt Mackall : http://www.selenic.com : Linux development and consulting
> > ndiswrapper has one use IMHO (which was pointed out me in this
> > thread)... to assist in reverse engineering.
>
> Hmm, maybe I've gotten the whole purpose of the thread wrong. =(
Still, I've looked into possibly reverse engineering the Broadcom
one for 802.11g from MacOS X (with 2 machines kernel debugging and
functions names embedded in the driver, it's not _that_ bad). But
it's a +500k binary .... I didn't go very far and decided I had
better ways to spend my time.
I know a lot of you don't care, but I hate in those discussions
about binary drivers when what is for me the #1 issue isn't even
mentioned: availability on non-x86 hardware !
Ben.
Matt Mackall wrote:
>On Thu, Nov 20, 2003 at 03:16:46PM +1100, Nick Piggin wrote:
>
>>
>>William Lee Irwin III wrote:
>>
>>
>>>Jean Tourrilhes wrote:
>>>
>>>
>>>>> Even better :
>>>>> 1) go to the Wireless LAN Howto
>>>>> 2) find a card are supported under Linux that suit your needs
>>>>> 3) buy this card
>>>>> I don't see the point of giving our money to vendors that
>>>>>don't care about us when there are vendors making a real effort toward
>>>>>us.
>>>>>
>>>>>
>>>On Wed, Nov 19, 2003 at 10:26:59PM -0500, Jeff Garzik wrote:
>>>
>>>
>>>>Unfortunately that leaves users without support for any recent wireless
>>>>hardware. It gets more and more difficult to even find Linux-supported
>>>>wireless at Fry's and other retail locations...
>>>>
>>>>
>>>And what good would it be to have an entire driver subsystem populated
>>>by binary-only drivers? That's not part of Linux, that's "welcome to
>>>nvidia hell" for that subsystem too, and not just graphics cards.
>>>
>>>I say we should go the precise opposite direction and take a hard line
>>>stance against binary drivers, lest we find there are none left we even
>>>have source to and are bombarded with unfixable bugreports.
>>>
>>>No, it's not my call to make, but basically, I don't see many benefits
>>>left. The additional drivers we got out of this were highly version-
>>>dependent, extremely fragile, and have been generating massive numbers
>>>of bugreports nonstop on a daily basis since their inception.
>>>
>>>We'd lose a few things, like vmware, but it's not worth the threat of
>>>vendors migrating en masse to NDIS/etc. emulation layers and dropping
>>>all spec publication and source drivers, leaving us entirely at the
>>>mercy of BBB's (Buggy Binary Blobs) to do any io whatsoever.
>>>
>>>Seriously, the binary-only business has been doing us a disservice, and
>>>is threatening to do worse.
>>>
>>>
>>You have to admit its good for end users though. And indirectly, what
>>is good for them is good for us.
>>
>
>No. It is bad for the end users - they get sold a bill of goods. And
>it is bad for developers. And it is bad for developers as users. And
>it's hopelessly short-sighted as pragmatism often is.
>
>Look, there's basically one thing that has ever historically enabled
>developers to get specs for writing decent Linux drivers, and that's
>demand from Linux users. If companies are presented with alternatives
>that pointy haired folks prefer like binary-only drivers or running
>their one and only Windows driver on an emulation layer, which are
>they going to choose and where are they going to tell users to stick
>their penguin? We'll be in worse shape than we were when no one had
>ever heard of Linux.
>
>Scenario to think about: an NDIS driver layer ends up getting firmed
>up and debugged and when the next generation of wireless appears,
>basically all vendors go the easy route and only ship NDIS drivers, no
>specs, and buggy as usual. Then they say hey, this worked out well,
>might as well do this with gigabit. Meanwhile, hardware's changing so
>quickly that by the time we manage to reverse-engineer any of this
>stuff (provided the legal climate allows it), it's already off the
>shelves. Two to three years from now, it's impossible to build a
>decent server or laptop that doesn't have bug-ridden, untested, low
>performance network drivers and all the reputation Linux has for being
>a good network OS goes down the tubes. It's safe to assume that
>latency and stability will go all to hell as well.
>
>An open operating system without open drivers is pointless and if we
>don't do something about all this binary crap soon, the above scenario
>-will- play out. Expect SCSI and perhaps sound to follow soon
>afterwards. And graphics cards and modems are obviously half-way there
>already.
>
>Personally, I think it's time to do some sort of trademark enforcement
>or something so that companies can't get away with slapping penguins
>on devices that only work with 2.2.14 Red Hat kernels.
>
>
Note I 100% disagree with any sort of emulation layer in the kernel.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
On Thursday 20 November 2003 05:38, William Lee Irwin III wrote:
> It's very much a second-class flavor of open source. They dare not
> change the kernel version lest the binary-only trainwreck explode.
We already have a second-class flavor of open source in the kernel right
now. There are drivers that do "magic value at magic address" in a quite
sophisticated manner. Combine this with firmware load from Windows DLLs
and you basically HAVE closed source, since the driver is on the device
itself and we just invoke it via i2c commands.
On NVidia drivers we might complain, that we don't see, which kernel
functions are used and for what. On these drivers we don't even see what
is done, since the device can issue DMA at will and thus scribble over
random kernel memory on firmware malfunction. And maybe this scribbling
is not that lethal to Windows for some reasons (e.g. area never used or
reserved area) so it will never be fixed.
Just have a look at some DVB hardware drivers. As much as I like *what*
is done there, I don't like how it is done.
What you call second-class is third-class already, since it also freezes
the kernel ABI and behavior forcably.
> They dare not run with the whiz-bang patches going around they're
> interested in lest the binary-only trainwreck explode. It may oops
> in mainline, and all they can do is wait for a tech support line to
> answer. Well, they're a little better than that, they have hackers
> out and about, but you're still stuck waiting for a specific small
> set of individuals and lose all of the "many eyes" advantages.
This "many eye" advantage is lost already by the type of drivers above
in kernel right now. Binary-only just adds to the pain by freezing
kernel<->module ABI.
Regards
Ingo Oeser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/vI/xU56oYWuOrkARAubfAJ4kIKlQvGbnPHxebnEQrqcfxOxMzQCeJ1Rz
jZ4toSAkd4Ry1LXNReuh2dc=
=zfYZ
-----END PGP SIGNATURE-----
On Thu, 20 Nov 2003, Matt Mackall wrote:
>> Personally, I think it's time to do some sort of trademark enforcement
>> or something so that companies can't get away with slapping penguins
>> on devices that only work with 2.2.14 Red Hat kernels.
On Thu, Nov 20, 2003 at 11:13:41AM +0100, Geert Uytterhoeven wrote:
> Indeed. What happened to the `works[*] with Linux' labelling proposal we
> discussed about at the last Linux Kernel Summit?
> [*] Meaning providing a decent source under a suitable license.
We may have to get Linus in on that.
-- wli
On Thu, 20 Nov 2003, Matt Mackall wrote:
> Personally, I think it's time to do some sort of trademark enforcement
> or something so that companies can't get away with slapping penguins
> on devices that only work with 2.2.14 Red Hat kernels.
Indeed. What happened to the `works[*] with Linux' labelling proposal we
discussed about at the last Linux Kernel Summit?
[*] Meaning providing a decent source under a suitable license.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
El Thu, 20 Nov 2003 15:59:46 +1100 Nick Piggin <[email protected]> escribi?:
> I must say that I've been using the same nvidia drivers on my desktop
> system for maybe a year, and never had a crash including going through
> countless versions of 2.5/6. True you need to recompile the intermediate
You're lucky.
Nvidia drivers are broken, and it's not just linux. Their windows drivers
are know to be buggy, too. And this is happening in windows (which has a
"windows driver model" abi which doesn't change even between W9x and nt)
Also, they don't support non-x86 architectures in linux (they have drivers
for mac os X though)
If there're a lot of binary drivers for linux, we'll have the same hell
microsoft has (w2k and XP are rock solid, until you start using crappy
drivers, then everybody complains about blue screens). A stable and defined
abi (like their driver model) doesn't work for them, it won't work for us.
I don't mind running propietary code...but not in the kernel.
(BTW, are there modern graphics cards with 100% opensource drivers?)
On Thu, Nov 20, 2003 at 01:41:21PM +0100, Diego Calleja Garc?a wrote:
> "windows driver model" abi which doesn't change even between W9x and nt)
that's what microsoft PR says. in fact it's rather difficult to have a driver
working on win9x and nt without very ugly hacks. And for some driver classes
it doesn't work at all.
Hi!
> > Pontus Fuchs wrote:
> > > Please! I don't want to start a flamewar if this is a good thing to do.
> > > I'm just trying to scratch my own itch and I doubt that this project
> > > changes the way Broadcom treats Linux users.
> >
> >
> > Then help us reverse engineer the driver :)
>
> Even better :
> 1) go to the Wireless LAN Howto
> 2) find a card are supported under Linux that suit your needs
> 3) buy this card
> I don't see the point of giving our money to vendors that
> don't care about us when there are vendors making a real effort toward
> us.
Unfortunately my broadcom came integrated within notebook.
More and more notebooks come with wifi installed...
Pavel
--
Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...
On Thursday 20 November 2003 01:52, Matt Mackall wrote:
[huge snip of well reasoned arguments]
>Personally, I think it's time to do some sort of trademark
> enforcement or something so that companies can't get away with
> slapping penguins on devices that only work with 2.2.14 Red Hat
> kernels.
Hear, hear! I'm still smarting over buying a copy of Wordperfect 8
for linux for $65 back in '98 or '99, only to find it wouldn't even
install if it didn't find some old, buggy 2.2.x kernel to run under.
The 2.4.x family was by then several generations old.
Shennanigans like that, screwing the customer (who had no recourse but
to seriously downgrade his system, no refunds were given) was one of
the things that Corel was very good at. And it no doubt heavily
contributed to the eventual failure of Corel. Potential Future
Customers remember that even if the PHB's can't. I removed my self
from that PFC list forthwith.
I keep it on the shelf as a reminder that I was one of those "Suckers
born every minute" :(
I'm for it, if it doesn't work with the latest stable kernel release,
the labels MUST COME OFF. But howto enforce that legally is the real
$64 question. Humm, I guess that dates me, I can remember that radio
program. From back in the '40's.
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
Ingo Oeser writes:
> We already have a second-class flavor of open source in the kernel right
> now. There are drivers that do "magic value at magic address" in a quite
> sophisticated manner. Combine this with firmware load from Windows DLLs
> and you basically HAVE closed source, since the driver is on the device
> itself and we just invoke it via i2c commands.
>
> On NVidia drivers we might complain, that we don't see, which kernel
> functions are used and for what. On these drivers we don't even see what
> is done, since the device can issue DMA at will and thus scribble over
> random kernel memory on firmware malfunction. And maybe this scribbling
> is not that lethal to Windows for some reasons (e.g. area never used or
> reserved area) so it will never be fixed.
>
> Just have a look at some DVB hardware drivers. As much as I like *what*
> is done there, I don't like how it is done.
Those drivers (at least the ones in the kernel right now) cannot issue any
DMA from inside the firmware. They also cannot crash the system, only
themselves. Basically they are like a separate computer connected via
a network-like connection (in this case dual ported RAM). The code
controlling the PCI bridge is open.
You are right that if the firmware can do things like initiating DMA
transfers this is a big problem. Of course this can also happen with
hardware which has bugs in permanently burnt-in microcode or even in the
silicon itself.
Regards,
Ralph Metzler
[email protected] said:
> Who brought binary drivers into this? And when I have ever advocated
> binary drivers?
>
> ndiswrapper has one use IMHO (which was pointed out me in this
> thread)... to assist in reverse engineering.
That may be your intention, but as soon as cards exist that can only be
made to work with ndis-wrapped drivers, you can be sure that the masses
won't wait for the reverse-engineering to be completed. So all the
nvidia-video-type problems _will_ start showing up in a big population
of laptops and such too.
Jason
On Thu, Nov 20, 2003 at 11:55:47AM +0100, Pavel Machek wrote:
> Hi!
>
> > > Pontus Fuchs wrote:
> > > > Please! I don't want to start a flamewar if this is a good thing to do.
> > > > I'm just trying to scratch my own itch and I doubt that this project
> > > > changes the way Broadcom treats Linux users.
> > >
> > >
> > > Then help us reverse engineer the driver :)
> >
> > Even better :
> > 1) go to the Wireless LAN Howto
> > 2) find a card are supported under Linux that suit your needs
> > 3) buy this card
> > I don't see the point of giving our money to vendors that
> > don't care about us when there are vendors making a real effort toward
> > us.
>
> Unfortunately my broadcom came integrated within notebook.
> More and more notebooks come with wifi installed...
> Pavel
Ask TyTso how you can change the MiniPCI card in laptops. I
think he even has a web page on the subject.
Good luck...
Jean
Jason Lunz wrote:
> [email protected] said:
>
>>Who brought binary drivers into this? And when I have ever advocated
>>binary drivers?
>>
>>ndiswrapper has one use IMHO (which was pointed out me in this
>>thread)... to assist in reverse engineering.
>
>
> That may be your intention, but as soon as cards exist that can only be
> made to work with ndis-wrapped drivers, you can be sure that the masses
> won't wait for the reverse-engineering to be completed. So all the
> nvidia-video-type problems _will_ start showing up in a big population
> of laptops and such too.
And we will ignore such bug reports, like we ignore nVidia bug reports
now. I welcome choice, including the choice of users to shoot
themselves in the foot...
Jeff
On Wed, Nov 19, 2003 at 08:00:34PM -0800, William Lee Irwin III wrote:
> Jean Tourrilhes wrote:
> >> Even better :
> >> 1) go to the Wireless LAN Howto
> >> 2) find a card are supported under Linux that suit your needs
> >> 3) buy this card
> >> I don't see the point of giving our money to vendors that
> >> don't care about us when there are vendors making a real effort toward
> >> us.
>
> On Wed, Nov 19, 2003 at 10:26:59PM -0500, Jeff Garzik wrote:
> > Unfortunately that leaves users without support for any recent wireless
> > hardware. It gets more and more difficult to even find Linux-supported
> > wireless at Fry's and other retail locations...
>
> And what good would it be to have an entire driver subsystem populated
> by binary-only drivers? That's not part of Linux, that's "welcome to
> nvidia hell" for that subsystem too, and not just graphics cards.
What's the point in ruminating academic scenario. There exist
fully open source drivers for quite a wide variety of modern wireless
LAN cards. It's not like if you don't have the choice.
Jean
On Thu, Nov 20, 2003 at 05:54:04PM +1100, Benjamin Herrenschmidt wrote:
>
> I know a lot of you don't care, but I hate in those discussions
> about binary drivers when what is for me the #1 issue isn't even
> mentioned: availability on non-x86 hardware !
That's why in the Howto the binary drivers are flagged
accordingly. I even add explicit PPC driver for drivers I know work on
PPC. What more do you need ?
I still don't understand why people buy the wrong
hardware. You have a choice, exercise it !
> Ben.
Regards,
Jean
On Thu, 20 Nov 2003, Jean Tourrilhes wrote:
> On Wed, Nov 19, 2003 at 08:00:34PM -0800, William Lee Irwin III wrote:
> > Jean Tourrilhes wrote:
> > >> Even better :
> > >> 1) go to the Wireless LAN Howto
> > >> 2) find a card are supported under Linux that suit your needs
> > >> 3) buy this card
> > >> I don't see the point of giving our money to vendors that
> > >> don't care about us when there are vendors making a real effort toward
> > >> us.
> >
> > On Wed, Nov 19, 2003 at 10:26:59PM -0500, Jeff Garzik wrote:
> > > Unfortunately that leaves users without support for any recent wireless
> > > hardware. It gets more and more difficult to even find Linux-supported
> > > wireless at Fry's and other retail locations...
> >
> > And what good would it be to have an entire driver subsystem populated
> > by binary-only drivers? That's not part of Linux, that's "welcome to
> > nvidia hell" for that subsystem too, and not just graphics cards.
>
> What's the point in ruminating academic scenario. There exist
> fully open source drivers for quite a wide variety of modern wireless
> LAN cards. It's not like if you don't have the choice.
>
> Jean
It's kinda interesting that several Wireless LAN boxen even
use Linux.... I suppose they don't want anybody to know
that, though....
Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
On Wed, Nov 19, 2003 at 08:00:34PM -0800, William Lee Irwin III wrote:
>> And what good would it be to have an entire driver subsystem populated
>> by binary-only drivers? That's not part of Linux, that's "welcome to
>> nvidia hell" for that subsystem too, and not just graphics cards.
On Thu, Nov 20, 2003 at 09:24:54AM -0800, Jean Tourrilhes wrote:
> What's the point in ruminating academic scenario. There exist
> fully open source drivers for quite a wide variety of modern wireless
> LAN cards. It's not like if you don't have the choice.
I wasn't quite aware of that when I made the post; prior discussions
had led me to believe the above scenario to be something approaching
the status quo.
-- wli
On Thu, Nov 20, 2003 at 01:41:21PM +0100, Diego Calleja Garc?a wrote:
> El Thu, 20 Nov 2003 15:59:46 +1100 Nick Piggin <[email protected]> escribi?:
>
> > I must say that I've been using the same nvidia drivers on my desktop
> > system for maybe a year, and never had a crash including going through
> > countless versions of 2.5/6. True you need to recompile the intermediate
>
> You're lucky.
> Nvidia drivers are broken, and it's not just linux. Their windows drivers
> are know to be buggy, too. And this is happening in windows (which has a
> "windows driver model" abi which doesn't change even between W9x and nt)
>
> Also, they don't support non-x86 architectures in linux (they have drivers
> for mac os X though)
> If there're a lot of binary drivers for linux, we'll have the same hell
> microsoft has (w2k and XP are rock solid, until you start using crappy
> drivers, then everybody complains about blue screens). A stable and defined
> abi (like their driver model) doesn't work for them, it won't work for us.
>
> I don't mind running propietary code...but not in the kernel.
>
> (BTW, are there modern graphics cards with 100% opensource drivers?)
>
None of the new chips (r300, any nvidia, matrox, etc) has opensource 3D
drivers.
If you want good 3D support (OpenGL) you need to use binary drivers :(
DRI (opensource) opengl-drivers have support for only ati r200 and older
cards.. so nothing new. And DRI drivers don't support the advanced features
of these cards.. so no shaders etc :(
OpenGL support in DRI drivers feels also more buggy than Nvidia/ATI binary
drivers :(
So the situation is not good..
-- Pasi K?rkk?inen
^
. .
Linux
/ - \
Choice.of.the
.Next.Generation.
On Thu, 20 Nov 2003, William Lee Irwin III wrote:
>> We may have to get Linus in on that.
On Thu, Nov 20, 2003 at 05:47:08PM -0500, Bill Davidsen wrote:
> Linux is a trademark. And if you don't defend it you lose it (like asprin
> and kleenex). So if he doesn't like the "Linux driver" from nvidia he can
> tell them to stop using the term. I'm not sure that's a good thing,
> however, they are more likely to drop support than open source IMHO.
Are we really going to cower when faced like an ultimatum like that?
-- wli
On Thu, 20 Nov 2003, William Lee Irwin III wrote:
> On Thu, 20 Nov 2003, Matt Mackall wrote:
> >> Personally, I think it's time to do some sort of trademark enforcement
> >> or something so that companies can't get away with slapping penguins
> >> on devices that only work with 2.2.14 Red Hat kernels.
>
> On Thu, Nov 20, 2003 at 11:13:41AM +0100, Geert Uytterhoeven wrote:
> > Indeed. What happened to the `works[*] with Linux' labelling proposal we
> > discussed about at the last Linux Kernel Summit?
> > [*] Meaning providing a decent source under a suitable license.
>
> We may have to get Linus in on that.
Linux is a trademark. And if you don't defend it you lose it (like asprin
and kleenex). So if he doesn't like the "Linux driver" from nvidia he can
tell them to stop using the term. I'm not sure that's a good thing,
however, they are more likely to drop support than open source IMHO.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
The problem is that they could very easily drop support for linux, then
what do we do?
We don't have any form of access to the top-of-the-line hardware needed
to run most new games, which means there'll be less incentive to try and
port them, so there's less reason to create drivers, ad infintum...
If anything the only thing we can really do is ask *politely* if they
could open more of the drivers...
--Oliver
William Lee Irwin III wrote:
>On Thu, 20 Nov 2003, William Lee Irwin III wrote:
>
>
>>>We may have to get Linus in on that.
>>>
>>>
>
>On Thu, Nov 20, 2003 at 05:47:08PM -0500, Bill Davidsen wrote:
>
>
>>Linux is a trademark. And if you don't defend it you lose it (like asprin
>>and kleenex). So if he doesn't like the "Linux driver" from nvidia he can
>>tell them to stop using the term. I'm not sure that's a good thing,
>>however, they are more likely to drop support than open source IMHO.
>>
>>
>
>Are we really going to cower when faced like an ultimatum like that?
>
>
>-- wli
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
On Thu, Nov 20, 2003 at 06:04:51PM -0500, Bill Davidsen wrote:
> On Wed, 19 Nov 2003, Jean Tourrilhes wrote:
>
> > Even better :
> > 1) go to the Wireless LAN Howto
> > 2) find a card are supported under Linux that suit your needs
> > 3) buy this card
> > I don't see the point of giving our money to vendors that
> > don't care about us when there are vendors making a real effort toward
> > us.
>
> You left out the step of "remove or disable the existing hardware in the
> system." Not everyone has a choice unlimited by budget and politics.
Why did you buy a bogus card in the first place ? That's
wasting money.
Jean
On Thu, 20 Nov 2003, William Lee Irwin III wrote:
> On Thu, 20 Nov 2003, William Lee Irwin III wrote:
> >> We may have to get Linus in on that.
>
> On Thu, Nov 20, 2003 at 05:47:08PM -0500, Bill Davidsen wrote:
> > Linux is a trademark. And if you don't defend it you lose it (like asprin
> > and kleenex). So if he doesn't like the "Linux driver" from nvidia he can
> > tell them to stop using the term. I'm not sure that's a good thing,
> > however, they are more likely to drop support than open source IMHO.
>
> Are we really going to cower when faced like an ultimatum like that?
What you me "we" here? Linus owns the trademark, he makes the decisions. I
can give him the name of a lawyer who did patent and trademark for GE for
decades, but I can't give him any advice. This is not a gut feel decision,
and "cower" sure sounds gut feel to me. That's probably not the optimal
consideration in this case. Failing to defend can mean losing a challenge
as well as doing nothing, the only advice I have on that is "consult a
good lawyer."
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Wed, 19 Nov 2003, Jean Tourrilhes wrote:
> Even better :
> 1) go to the Wireless LAN Howto
> 2) find a card are supported under Linux that suit your needs
> 3) buy this card
> I don't see the point of giving our money to vendors that
> don't care about us when there are vendors making a real effort toward
> us.
You left out the step of "remove or disable the existing hardware in the
system." Not everyone has a choice unlimited by budget and politics.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
[ replying to several posts ]
On Thu, 20 Nov 2003, Jean Tourrilhes wrote:
> That's why in the Howto the binary drivers are flagged
> accordingly. I even add explicit PPC driver for drivers I know work on
> PPC. What more do you need ?
> I still don't understand why people buy the wrong
> hardware. You have a choice, exercise it !
On Thu, 20 Nov 2003, Jean Tourrilhes wrote:
> > And what good would it be to have an entire driver subsystem populated
> > by binary-only drivers? That's not part of Linux, that's "welcome to
> > nvidia hell" for that subsystem too, and not just graphics cards.
>
> What's the point in ruminating academic scenario. There exist
> fully open source drivers for quite a wide variety of modern wireless
> LAN cards. It's not like if you don't have the choice.
Unfortunately in the real world, many people *don't* have a choice. They
are limited to using what they can afford, or what their employer,
university, or thesis advisor provides or requires. People also have
system with built-in devices which either can't be removed or which will
void waranty if the devices are removed.
If the NDIS software allows development of OS drivers for the hardware
people *must* use, then they will at least have a choice of the operating
system. And if it improves reverse engineering some companies will avoid
NDIS just for that reason. Sounds like two good results to me.
The idea that all vendors would drop open spec and open source is totally
unrelated to reality, some companies provided that information when the
Linux market was tiny, they are not going to change, and neither are the
companies who don't release info now.
I'm curious if the NDIS stuff could be run in ring 1 or 2, being an old
MULTICS guy. Not for political reasons, just good tech.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Fri, Nov 21, 2003 at 10:57:19AM +1100, Benjamin Herrenschmidt wrote:
>
> Except when Apple provides built-in Broadcom chipset in all new
> recent Macs...
Only one world : monopoly...
> Ben.
Jean
On Thu, Nov 20, 2003 at 04:53:12PM -0700, Mudama, Eric wrote:
>
> I think the point being made is "Why spend an extra $150 on a PCMCIA wifi
> card when there's an integrated wifi device already in the laptop that
> ndiswrapper will allow to sortof work?"
>
> The person who bought this laptop and wants to run linux on it might not
> have the extra money handy to use buying additional hardware.
>
> Not my point of view, but definitely "a" point of view.
>
> --eric
My point is : why buy this laptop if it's not 100%
supported ? They are plenty of other laptops...
I can guarantee you that I'm more picky and more cheap than
anyone when choosing laptops, and I always get something 100%
supported.
Jean
I think the point being made is "Why spend an extra $150 on a PCMCIA wifi
card when there's an integrated wifi device already in the laptop that
ndiswrapper will allow to sortof work?"
The person who bought this laptop and wants to run linux on it might not
have the extra money handy to use buying additional hardware.
Not my point of view, but definitely "a" point of view.
--eric
> -----Original Message-----
> From: Jean Tourrilhes [mailto:[email protected]]
> Sent: Thursday, November 20, 2003 4:45 PM
> To: Bill Davidsen
> Cc: Linux kernel mailing list
> Subject: Re: Announce: ndiswrapper
>
>
> On Thu, Nov 20, 2003 at 06:04:51PM -0500, Bill Davidsen wrote:
> > You left out the step of "remove or disable the existing
> hardware in the
> > system." Not everyone has a choice unlimited by budget and politics.
>
> Why did you buy a bogus card in the first place ? That's
> wasting money.
>
> Jean
On Thu, 20 Nov 2003, Matt Mackall wrote:
> Scenario to think about: an NDIS driver layer ends up getting firmed
> up and debugged and when the next generation of wireless appears,
> basically all vendors go the easy route and only ship NDIS drivers, no
> specs, and buggy as usual. Then they say hey, this worked out well,
> might as well do this with gigabit. Meanwhile, hardware's changing so
> quickly that by the time we manage to reverse-engineer any of this
> stuff (provided the legal climate allows it), it's already off the
> shelves. Two to three years from now, it's impossible to build a
> decent server or laptop that doesn't have bug-ridden, untested, low
> performance network drivers and all the reputation Linux has for being
> a good network OS goes down the tubes. It's safe to assume that
> latency and stability will go all to hell as well.
>
> An open operating system without open drivers is pointless and if we
> don't do something about all this binary crap soon, the above scenario
> -will- play out. Expect SCSI and perhaps sound to follow soon
> afterwards. And graphics cards and modems are obviously half-way there
> already.
You left out the black helicopters... the reason vendors support Linux is
to sell product. If the driver doesn't work well some number of people
will either debug and fix the problem (source) or not buy the product
(binary). And giving out the spec and letting someone else do the driver
is even better, no work, no cost, no liability for bugs.
I think the vendors who feel that they have something to hide are the
exception, and rumor has it that fixes in Linux drivers migrate back into
Windows drivers, another fringe benefit.
> Personally, I think it's time to do some sort of trademark enforcement
> or something so that companies can't get away with slapping penguins
> on devices that only work with 2.2.14 Red Hat kernels.
On that I agree, but remember that only one Penguin has a vote on that. A
Trademark must be defended or it will be lost, maybe this would be a good
place to start. Let a lawyer advise on stuff like that.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Fri, 2003-11-21 at 04:27, Jean Tourrilhes wrote:
> On Thu, Nov 20, 2003 at 05:54:04PM +1100, Benjamin Herrenschmidt wrote:
> >
> > I know a lot of you don't care, but I hate in those discussions
> > about binary drivers when what is for me the #1 issue isn't even
> > mentioned: availability on non-x86 hardware !
>
> That's why in the Howto the binary drivers are flagged
> accordingly. I even add explicit PPC driver for drivers I know work on
> PPC. What more do you need ?
> I still don't understand why people buy the wrong
> hardware. You have a choice, exercise it !
Except when Apple provides built-in Broadcom chipset in all new
recent Macs...
Ben.
Jean Tourrilhes [[email protected]] wrote:
>
> My point is : why buy this laptop if it's not 100%
> supported ? They are plenty of other laptops...
There are not plenty. By the time you limit yourself to:
1) No nvidia
2) Supported wireless
3) Non-winmodem
4) OSS driver for sound
5) Not paying for windoze
you're left with a fairly small set of laptops and vendors, and I
haven't even started considering the hardware I *do* want yet.
(processor, HDD, RAM, screen, etc)
For the record I maintain a list of linux and no-OS laptop vendors:
http://mcelrath.org/laptops.html
and there aren't that many. Go through there product lines and start
cutting out winmodems, broadcam wireless and nvidia, and there is very
little left.
The problem is consumers don't build laptops, companies do. I can build
my desktop component-by-component. (Rally now for open, interchangable
laptop hardware!)
Cheers,
Bob McElrath [Univ. of California at Davis, Department of Physics]
Hi,
On November 20, 2003 02:00 am, Benjamin Herrenschmidt wrote:
> Still, I've looked into possibly reverse engineering the Broadcom
> one for 802.11g from MacOS X (with 2 machines kernel debugging and
> functions names embedded in the driver, it's not _that_ bad). But
> it's a +500k binary .... I didn't go very far and decided I had
> better ways to spend my time.
>
Just in case anyone here is interested, a few of us over at
linux-bcom4301.sourceforge.net have been working (albeit slowly) at reverse
engineering this driver.
Actually, one ongoing project is to get the Broadcom driver with ndiswrapper
to run inside an emulator like bochs, so we can monitor all the IO.
Actually, something I posted last week about doing DMA to userspace was for
this project.
For reference, Linksys has provided the source code for the components of the
Broadcom wireless driver that are statically linked with the kernels included
in many of their new 802.11g wireless products [1]. However, there remains a
component that we still have in binary-only form.
For the curious, the total size of the binary-only part is 386K of mipsel
code. We also have this module in it's unlinked form.
I've looked at a few functions to see how simple it would be to reverse
engineer. Some of it is pretty easy to follow. However, there are parts
that become very complicated, where they start doing branches on conditions
like: "if it is a BCM4301 chip, integrated on a Dell board, where the core
revision is less than ver. X then set some flag".
-- Andrew
[1] http://www.linksys.com/support/opensourcecode/wap54g/wap54g.1.08.tar.gz
(Download the WAP54G package)
Followup to: <[email protected]>
By author: Bill Davidsen <[email protected]>
In newsgroup: linux.dev.kernel
>
> I'm curious if the NDIS stuff could be run in ring 1 or 2, being an old
> MULTICS guy. Not for political reasons, just good tech.
>
Unfortunately the segmentation and paging were so poorly integrated in
i386 that rings 1-2 are pretty much totally useless.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
If you send me mail in HTML format I will assume it's spam.
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
On 20 Nov 2003, H. Peter Anvin wrote:
> By author: Bill Davidsen <[email protected]>
> >
> > I'm curious if the NDIS stuff could be run in ring 1 or 2, being an old
> > MULTICS guy. Not for political reasons, just good tech.
>
> Unfortunately the segmentation and paging were so poorly integrated in
> i386 that rings 1-2 are pretty much totally useless.
That may be the politically sensitive (except to Intel) correct answer,
but in the end I suspect that the _real_ answer is that ring 1/2 are just
fundamentally useless, and it has nothing to do with x86 implementation
semantics or anything else.
Any kind of reasonable performance driver requires direct access to the
buffers it is going to fill in. And not just the actual data contents, but
to the metadata too - the pointers that comprise the skb (or in BSD, mbuf)
lists, etc.
So even if you were to use ring1/2 for the driver, you'd really need to
give write access to a large portion of the data structures that the
"core" kernel networking would use.
Which means that you either put the core kernel in ring1/2 as well (at
which point you don't actually use ring0 for anything interesting at all -
you could put a microkernel there, but hey, there's no real point), or you
map in a _lot_ of ring0 metadata into ring1/2, at which point you lost the
whole point of using a different protection domain.
And quite frankly, if you're willing to actually dynamically map all the
ranges and be careful, why use ring1/2 at all? You might as well use ring3
and make the whole thing be a user-mode wrapper. You'd never perform
really well, but for debugging it is acceptable.
Anyway, whatever way you turn, ring1/2 just don't actually _give_ you
anything. Which is, in the end, the _real_ reason nobody uses them.
(I agree, the fact that the x86 paging hardware makes 1/2/3 be equivalent
makes it an even _less_ useful abstraction, but I think it is a mistake to
think that it would be any more useful even if the page tables wasted
precious bits on unnecessary level information).
Multi-ring was a failure. Let it go. The only reason it is making
something of a comeback (Palladium-whatever-it-is-called-today) has no
good technical reasons, and is purely about other things.
Linus
Linus Torvalds wrote:
>
> (I agree, the fact that the x86 paging hardware makes 1/2/3 be equivalent
> makes it an even _less_ useful abstraction, but I think it is a mistake to
> think that it would be any more useful even if the page tables wasted
> precious bits on unnecessary level information).
>
Actually, the paging hardware makes 0/1/2 equivalent; some *other*
primitives make 1/2/3 equivalent...
>
> Multi-ring was a failure. Let it go. The only reason it is making
> something of a comeback (Palladium-whatever-it-is-called-today) has no
> good technical reasons, and is purely about other things.
>
No doubt. However, I wish they would have at least taken the few useful
thing they had in the i286 botch, like the RPL, and made them available
to the paging system. That way i386 would have had "access this as from
user space" like most architectures have.
-hpa
Linus Torvalds wrote:
[...]
>
>
> That may be the politically sensitive (except to Intel) correct answer,
> but in the end I suspect that the _real_ answer is that ring 1/2 are just
> fundamentally useless, and it has nothing to do with x86 implementation
> semantics or anything else.
>
(A bit OT, but...)
Hi Linus!
The good people at Cambridge made a (very nice) VMM that exploits
ring0/1/3 to let one machine run various kernels independently (the
kernels need to be ported to the xen arch).
Xen itself executes in ring0 and the "guest" operating systems execute
in ring1. User code runs in ring3, as usual. They have linux running
under xen ;)
The project's home page is at
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ and one paper describing
the whole thing is here:
http://www.cl.cam.ac.uk/netos/papers/2003-xensosp.pdf
Regards,
Nuno Silva
On Fri, 21 Nov 2003, Nuno Silva wrote:
>
> The good people at Cambridge made a (very nice) VMM that exploits
> ring0/1/3 to let one machine run various kernels independently (the
> kernels need to be ported to the xen arch).
This is what I alluded to a few lines later - saying that if you move the
driver down to ring1, then you should move _everything_ down to ring1 and
just leave a microkernel at ring0.
Now, I'm not big on microkernels, but a pure virtual machine abstraction
is at least not the distateful academic mental masturbation that we saw in
the 80's.
Linus
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Friday 21 November 2003 01:00, Jean Tourrilhes wrote:
> On Thu, Nov 20, 2003 at 04:53:12PM -0700, Mudama, Eric wrote:
> > I think the point being made is "Why spend an extra $150 on a PCMCIA wifi
> > card when there's an integrated wifi device already in the laptop that
> > ndiswrapper will allow to sortof work?"
> >
> > The person who bought this laptop and wants to run linux on it might not
> > have the extra money handy to use buying additional hardware.
> >
> > Not my point of view, but definitely "a" point of view.
> >
> > --eric
>
> My point is : why buy this laptop if it's not 100%
> supported ? They are plenty of other laptops...
> I can guarantee you that I'm more picky and more cheap than
> anyone when choosing laptops, and I always get something 100%
> supported.
I, too, am the owner of a 'centrino' laptop, which comes with the intel Pro/
wireless 2100 card. At the time I bought it, Intel said that they would be
providing linux support for centrino, and since they made good on their
claims in the past, I went ahead and bought it. Unfortunately, until now,
they haven't substansiated that claim yet. And, I'm not really willing to
cough up another 150-200 EUR for another minipci card, which - in some cases
- - even has to be of a specific type to work with the bios of the system!
So, driverloader or ndiswrapper provides me with a workable solution, even
though it's not really the way I like it. But it works. That's what counts
for the majority of the 'desktop/laptop' linux users. They don't care how it
happens, as long as it happens.
Personally I'm only half in that camp, since I like to use opensource & free
drivers/software if available, and will advocate the use of such software. If
no decent os substitutes are available, I'll use proprietary/binary only
stuff nevertheless.
Jan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/vcWiUQQOfidJUwQRAp8dAJ9vxrt7K2nC9JkJgzGNw1ewsgrjNQCfTtMy
P8eS3BHEjw/eBxzKNLveVMk=
=/vnv
-----END PGP SIGNATURE-----
Jean Tourrilhes wrote:
> On Thu, Nov 20, 2003 at 04:53:12PM -0700, Mudama, Eric wrote:
> >
> > I think the point being made is "Why spend an extra $150 on a PCMCIA wifi
> > card when there's an integrated wifi device already in the laptop that
> My point is : why buy this laptop if it's not 100%
> supported ? They are plenty of other laptops...
Sometimes people don't buy new laptops, they get given them or buy a
cheap one second hand. Such people can't afford a wireless card, or
to choose hardware, so it's nice if they can use what they have.
Why, only a couple of weeks ago I installed Debian on a Pentium 233
which someone was delighted to be given. Old computers are cheap, but
some people can't afford $50 let alone $150.
-- Jamie
> Actually, one ongoing project is to get the Broadcom driver with ndiswrapper
> to run inside an emulator like bochs, so we can monitor all the IO.
> Actually, something I posted last week about doing DMA to userspace was for
> this project.
If you can get this to run in userspace I can provide an IO-trace enabled
strace for x86 (which is still in the works but will likely be enough for
you).
Cheers,
MaZe.
On Wed, Nov 19, 2003 at 07:34:22PM -0800, Jean Tourrilhes wrote:
> > > Even better :
> > > 1) go to the Wireless LAN Howto
> > > 2) find a card are supported under Linux that suit your needs
> > > 3) buy this card
> > > I don't see the point of giving our money to vendors that
> > >don't care about us when there are vendors making a real effort toward
> > >us.
> >
> >
> > Unfortunately that leaves users without support for any recent wireless
> > hardware.
>
> Excuse me ? Have you looked at the Howto lately ? There is
> only Broadcom and Intel which are not supported, which leaves plenty
> of choice (including many 802.11g and 802.11a cards).
And Realtek (I own one such card) and ADMtek (I bought one by accident
in Canada) and Atheros and ... basically anything CardBus doesn't work.
Well, you might say that those have Linux drivers, although they're
binary only, but that's about as useful as none if one has a 2.6 kernel.
> > It gets more and more difficult to even find Linux-supported
> > wireless at Fry's and other retail locations...
>
> If you are careful, you can even buy at Fry's. I bought
> recently some Microsoft cards ;-)
>
> > Jeff
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Fri, Nov 21, 2003 at 01:05:34PM +0100, Vojtech Pavlik wrote:
> On Wed, Nov 19, 2003 at 07:34:22PM -0800, Jean Tourrilhes wrote:
>
> > Excuse me ? Have you looked at the Howto lately ? There is
> > only Broadcom and Intel which are not supported, which leaves plenty
> > of choice (including many 802.11g and 802.11a cards).
>
> And Realtek (I own one such card) and ADMtek (I bought one by accident
> in Canada) and Atheros and ... basically anything CardBus doesn't work.
Wrong. There are wireless drivers for RealTek, ADMtek and
Atheros.
I may repeat myself like a parrot, but "Have you looked at the
Howto lately ?". I think you exactly prove my point ;-)
Jean
Jean Tourrilhes wrote:
> On Fri, Nov 21, 2003 at 01:05:34PM +0100, Vojtech Pavlik wrote:
>
>>On Wed, Nov 19, 2003 at 07:34:22PM -0800, Jean Tourrilhes wrote:
>>
>>
>>> Excuse me ? Have you looked at the Howto lately ? There is
>>>only Broadcom and Intel which are not supported, which leaves plenty
>>>of choice (including many 802.11g and 802.11a cards).
>>
>>And Realtek (I own one such card) and ADMtek (I bought one by accident
>>in Canada) and Atheros and ... basically anything CardBus doesn't work.
>
>
> Wrong. There are wireless drivers for RealTek, ADMtek and
> Atheros.
> I may repeat myself like a parrot, but "Have you looked at the
> Howto lately ?". I think you exactly prove my point ;-)
Last I checked, none of these were 100% open source. I am certain this
is true for Atheros, but IIRC it's also the case for the other two?
Anyway, WRT RealTek, they gave me (and others) docs. If I can locate a
card, I'll do a driver (or merge an existing one, if any). RealTek's
been pretty supportive of open source in the past, what with
8139too/8139cp/r8169 stuff.
Jeff
On Fri, Nov 21, 2003 at 12:30:47PM -0500, Jeff Garzik wrote:
> Jean Tourrilhes wrote:
> >On Fri, Nov 21, 2003 at 01:05:34PM +0100, Vojtech Pavlik wrote:
> >
> >>On Wed, Nov 19, 2003 at 07:34:22PM -0800, Jean Tourrilhes wrote:
> >>
> >>
> >>> Excuse me ? Have you looked at the Howto lately ? There is
> >>>only Broadcom and Intel which are not supported, which leaves plenty
> >>>of choice (including many 802.11g and 802.11a cards).
> >>
> >>And Realtek (I own one such card) and ADMtek (I bought one by accident
> >>in Canada) and Atheros and ... basically anything CardBus doesn't work.
> >
> >
> > Wrong. There are wireless drivers for RealTek, ADMtek and
> >Atheros.
> > I may repeat myself like a parrot, but "Have you looked at the
> >Howto lately ?". I think you exactly prove my point ;-)
>
>
> Last I checked, none of these were 100% open source. I am certain this
> is true for Atheros, but IIRC it's also the case for the other two?
>
> Anyway, WRT RealTek, they gave me (and others) docs. If I can locate a
> card, I'll do a driver (or merge an existing one, if any). RealTek's
> been pretty supportive of open source in the past, what with
> 8139too/8139cp/r8169 stuff.
If you want, I will send you one. The Edimax EW-7106PC is a Realtek based card.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Fri, Nov 21, 2003 at 12:30:47PM -0500, Jeff Garzik wrote:
>
> Last I checked, none of these were 100% open source. I am certain this
> is true for Atheros, but IIRC it's also the case for the other two?
Ha ! Now we are talking ;-) But this as well is fully
specified in the Howto... Yes, all those cards have binary drivers
made for Linux (which is much better than nothing).
> Anyway, WRT RealTek, they gave me (and others) docs. If I can locate a
> card, I'll do a driver (or merge an existing one, if any).
Another link from the Howto ;-)
http://www.linux-wlan.org/docs/wlan_adapters.html
> RealTek's
> been pretty supportive of open source in the past, what with
> 8139too/8139cp/r8169 stuff.
That would be real cool ;-) Thanks for your work Jeff.
> Jeff
Jean
On Thu, 20 Nov 2003, Jean Tourrilhes wrote:
> On Thu, Nov 20, 2003 at 06:04:51PM -0500, Bill Davidsen wrote:
> > On Wed, 19 Nov 2003, Jean Tourrilhes wrote:
> >
> > > Even better :
> > > 1) go to the Wireless LAN Howto
> > > 2) find a card are supported under Linux that suit your needs
> > > 3) buy this card
> > > I don't see the point of giving our money to vendors that
> > > don't care about us when there are vendors making a real effort toward
> > > us.
> >
> > You left out the step of "remove or disable the existing hardware in the
> > system." Not everyone has a choice unlimited by budget and politics.
>
> Why did you buy a bogus card in the first place ? That's
> wasting money.
The most common reason is that someone else, like employer or university,
specifies or even provides the hardware. After that comes system price, a
system with a less-than-perfect device may be much cheaper than the
perfect solution. Many people have a low money to time ratio, and when
affordable hardware becomes available it's only possible to use it. And in
some cases the offending hardware may be unremovable, as in soldered on.
Think laptop.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Fri, Nov 21, 2003 at 09:25:41AM -0800, Jean Tourrilhes wrote:
> On Fri, Nov 21, 2003 at 01:05:34PM +0100, Vojtech Pavlik wrote:
> > On Wed, Nov 19, 2003 at 07:34:22PM -0800, Jean Tourrilhes wrote:
> >
> > > Excuse me ? Have you looked at the Howto lately ? There is
> > > only Broadcom and Intel which are not supported, which leaves plenty
> > > of choice (including many 802.11g and 802.11a cards).
> >
> > And Realtek (I own one such card) and ADMtek (I bought one by accident
> > in Canada) and Atheros and ... basically anything CardBus doesn't work.
>
> Wrong. There are wireless drivers for RealTek, ADMtek and
> Atheros.
> I may repeat myself like a parrot, but "Have you looked at the
> Howto lately ?". I think you exactly prove my point ;-)
Yes, I've looked at the howto several times, and even downloaded the
drivers.
You may have missed the second paragraph I wrote:
>>> Well, you might say that those have Linux drivers, although they're
>>> binary only, but that's about as useful as none if one has a 2.6 kernel.
Now I was wrong in a couple points:
As Linus pointed to me, the Atheros driver now works even with 2.6.
They're not binary only, but part-binary, which is somewhat better
(not dependent on exact kernel version, just on compiler version and
kernel major version).
But still both the Realtek and ADMtek drivers are useless with 2.6.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Thu, 20 Nov 2003, Nick Piggin wrote:
> I guess they're tracable for nvidia.
Unless the system has a second binary only driver loaded,
from another vendor.
Then the system is essentially unsupportable, regardless of
how much money the user has paid for the support contract.
In that case the "good support" advantage of Linux disappears.
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
Hi!
> > My point is : why buy this laptop if it's not 100%
> > supported ? They are plenty of other laptops...
>
> There are not plenty. By the time you limit yourself to:
> 1) No nvidia
> 2) Supported wireless
> 3) Non-winmodem
> 4) OSS driver for sound
> 5) Not paying for windoze
> you're left with a fairly small set of laptops and vendors, and I
> haven't even started considering the hardware I *do* want yet.
> (processor, HDD, RAM, screen, etc)
Add "working ACPI" to the list.
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]