Re: Announce: ndiswrapper

Re: Announce: ndiswrapper

[Jean Tourrilhes]

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

Re: Announce: ndiswrapper

[Jeff Garzik]

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

Re: Announce: ndiswrapper

[Jean Tourrilhes]

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

Re: Announce: ndiswrapper

[William Lee Irwin III]

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

Re: Announce: ndiswrapper

[Nick Piggin]

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.

Re: Announce: ndiswrapper

[Neil Brown]

On Thursday November 20, piggin@cyberone.com.au 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

Re: Announce: ndiswrapper

[William Lee Irwin III]

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

Re: Announce: ndiswrapper

[Nick Piggin]

Neil Brown wrote:

>On Thursday November 20, piggin@cyberone.com.au 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.

Re: Announce: ndiswrapper

[Randy.Dunlap]

On Thu, 20 Nov 2003 15:49:05 +1100 Nick Piggin <piggin@cyberone.com.au> wrote:

| Neil Brown wrote:
| 
| >On Thursday November 20, piggin@cyberone.com.au 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

Re: Announce: ndiswrapper

[Nick Piggin]

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.

Re: Announce: ndiswrapper

[Nick Piggin]

Randy.Dunlap wrote:

>On Thu, 20 Nov 2003 15:49:05 +1100 Nick Piggin <piggin@cyberone.com.au> 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?

Re: Announce: ndiswrapper

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1522 bytes --]

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 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.


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Announce: ndiswrapper

[William Lee Irwin III]

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

Re: Announce: ndiswrapper

[Jeff Garzik]

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

Re: Announce: ndiswrapper

[William Lee Irwin III]

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

Re: Announce: ndiswrapper

[Nick Piggin]

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.

Re: Announce: ndiswrapper

[William Lee Irwin III]

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

Re: Announce: ndiswrapper

[Jeff Garzik]

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

Re: Announce: ndiswrapper

[Nick Piggin]

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.

Re: Announce: ndiswrapper

[Benjamin Herrenschmidt]

> We don't, nvidia does (directly or through a distro).
> We provide choice, right?

To x86 users only :(

Ben.

Re: Announce: ndiswrapper

[Matt Mackall]

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

Re: Announce: ndiswrapper

[Benjamin Herrenschmidt]

> > 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.

Re: Announce: ndiswrapper

[Nick Piggin]

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.

Re: Announce: ndiswrapper

[Ingo Oeser]

-----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-----

Re: Announce: ndiswrapper

[Geert Uytterhoeven]

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 -- geert@linux-m68k.org

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

Re: Announce: ndiswrapper

[William Lee Irwin III]

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

Re: Announce: ndiswrapper

[Pavel Machek]

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...

Re: Announce: ndiswrapper

[Diego Calleja García]

El Thu, 20 Nov 2003 15:59:46 +1100 Nick Piggin <piggin@cyberone.com.au> 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?)

Re: Announce: ndiswrapper

[Christoph Hellwig]

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.

Re: Announce: ndiswrapper

[Ralph Metzler]

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

Re: Announce: ndiswrapper

[Gene Heskett]

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.

Re: Announce: ndiswrapper

[Jason Lunz]

jgarzik@pobox.com 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

Re: Announce: ndiswrapper

[Jean Tourrilhes]

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

Re: Announce: ndiswrapper

[Jean Tourrilhes]

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

Re: Announce: ndiswrapper

[Jean Tourrilhes]

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

Re: Announce: ndiswrapper

[Jeff Garzik]

Jason Lunz wrote:
> jgarzik@pobox.com 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

Re: Announce: ndiswrapper

[Richard B. Johnson]

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.

Re: Announce: ndiswrapper

[William Lee Irwin III]

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

Re: Announce: ndiswrapper

[Pasi Kärkkäinen]

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 <piggin@cyberone.com.au> 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.

Re: Announce: ndiswrapper

[Bill Davidsen]

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 <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Announce: ndiswrapper

[William Lee Irwin III]

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

Re: Announce: ndiswrapper

[Bill Davidsen]

[ 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 <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Announce: ndiswrapper

[Bill Davidsen]

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 <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Announce: ndiswrapper

[Bill Davidsen]

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 <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Announce: ndiswrapper

[Oliver Hunt]

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 majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>  
>

Re: Announce: ndiswrapper

[Bill Davidsen]

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 <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Announce: ndiswrapper

[Jean Tourrilhes]

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

Re: Announce: ndiswrapper

[Benjamin Herrenschmidt]

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.

Re: Announce: ndiswrapper

[Jean Tourrilhes]

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

Re: Announce: ndiswrapper

[H. Peter Anvin]

Followup to:  <Pine.LNX.3.96.1031120174823.11021B-100000@gatekeeper.tmr.com>
By author:    Bill Davidsen <davidsen@tmr.com>
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
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> 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

Re: Announce: ndiswrapper

[Linus Torvalds]

On 20 Nov 2003, H. Peter Anvin wrote:
> By author:    Bill Davidsen <davidsen@tmr.com>
> > 
> > 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

Re: Announce: ndiswrapper

[H. Peter Anvin]

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

Re: Announce: ndiswrapper

[Nuno Silva]

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

Re: Announce: ndiswrapper

[Linus Torvalds]

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

Re: Announce: ndiswrapper

[Vojtech Pavlik]

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

Re: Announce: ndiswrapper

[Bill Davidsen]

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 <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Announce: ndiswrapper

[Jean Tourrilhes]

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

Re: Announce: ndiswrapper

[Jeff Garzik]

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

Re: Announce: ndiswrapper

[Vojtech Pavlik]

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

Re: Announce: ndiswrapper

[Jean Tourrilhes]

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

Re: Announce: ndiswrapper

[Vojtech Pavlik]

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

Re: Announce: ndiswrapper

[Jan Rychter]

[-- Attachment #1: Type: text/plain, Size: 2428 bytes --]

>>>>> "Jean" == Jean Tourrilhes <jt@bougret.hpl.hp.com> writes:
 Jean> 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

 Jean> Even better :
 Jean> 1) go to the Wireless LAN Howto
 Jean> 2) find a card are supported under Linux that suit your needs
 Jean> 3) buy this card
 Jean> I don't see the point of giving our money to vendors that don't
 Jean> care about us when there are vendors making a real effort toward
 Jean> us.  Regards,

Unfortunately, this means you can't buy a "Centrino"-based
laptop. Actually, that pretty much means you can't get any recent
laptop.

I'd like on this occasion to remind everyone that Intel left Linux out
in the cold in spite of loud announcements of upcoming Linux support for
the "Centrino" marketing thing (see for example
http://news.com.com/2100-1006-993896.html or
http://zdnet.com.com/2100-1103-993896.html or
http://www.intel.com/support/notebook/centrino/sb/cs-006059-prd955.htm).

There is of course the "Intel Support of Centrino Under Linux" petition
(http://www.petitiononline.com/xanthan/petition.html), which seems to
have done some good as the aforementioned Intel page has been updated to
say the drivers are "under development".

Still, even if they are "under development", this means some other
operating systems have had an unfair over one-year advantage over
Linux. That's a *big, long* advantage.

I'm a bit surprised that nobody has sued Intel yet for unfair market
practices, as providing documentation on chipset workings to select
vendors certainly constitutes one. But I guess that's politics, nobody
wants to mess with the big guys, it's better to play along and get early
access to server architectures.

I find it rather sad that Michael Robertson has so far been the only one
to speak up: http://www.theregister.co.uk/content/4/29840.html. Why is
RedHat (for example) sitting quietly? Whining about lack of success of
Linux on the desktop seems to be a silly thing to do if Linux doesn't
even WORK properly on the desktop machine.

The reason I wrote this posting is because I think reverse-engineering
the drivers forever is not a long-term solution. Vendors should start
feeling the pressure.

--J.

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Announce: ndiswrapper

[Rik van Riel]

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

Re: Announce: ndiswrapper

[Pavel Machek]

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?]

Re: Announce: ndiswrapper

[Maciej Zenczykowski]

> 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.

Re: Announce: ndiswrapper

[Jamie Lokier]

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

Re: Announce: ndiswrapper

[Jan De Luyck]

-----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-----

Re: Announce: ndiswrapper

[Andrew Miklas]

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)

Re: Announce: ndiswrapper

[Bob McElrath]

[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]

Jean Tourrilhes [jt@bougret.hpl.hp.com] 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]

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Announce: ndiswrapper

[Jean Tourrilhes]

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

RE: Announce: ndiswrapper

[Mudama, Eric]

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:jt@bougret.hpl.hp.com]
> 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

Re: Announce: ndiswrapper

[Pavel Machek]

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?]

Re: Announce: ndiswrapper

[Maciej Zenczykowski]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1950 bytes --]

> > 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.

[-- Attachment #2: Type: TEXT/PLAIN, Size: 20282 bytes --]

diff -urN strace-4.5/defs.h strace-4.5mz/defs.h
--- strace-4.5/defs.h	2003-08-21 11:58:00.000000000 +0200
+++ strace-4.5mz/defs.h	2003-11-15 16:08:25.000000000 +0100
@@ -284,6 +284,14 @@
 	int nclone_threads;	/* # of nchildren with CLONE_THREAD */
 	int nclone_detached;	/* # of nchildren with CLONE_DETACHED */
 	int nclone_waiting;	/* clone threads in wait4 (TCB_SUSPENDED) */
+#ifdef I386	
+	int ioscno;
+	int ioretval;
+	int iopl;
+	char cap_rawio;
+#define MAX_IOPERM 1024
+	unsigned char io_bitmap[MAX_IOPERM / 8 + 1];
+#endif
 #endif
 				/* (1st arg of wait4()) */
 	long baddr;		/* `Breakpoint' address */
@@ -395,7 +403,7 @@
 extern struct tcb **tcbtab;
 extern int qual_flags[];
 extern int debug, followfork, followvfork;
-extern int rflag, tflag, dtime, cflag, xflag, qflag;
+extern int rflag, tflag, dtime, cflag, ioflag, xflag, qflag;
 extern int acolumn;
 extern char *outfname;
 extern unsigned int nprocs, tcbtabsize;
@@ -456,6 +464,9 @@
 extern void tprint_iov P((struct tcb *, int, long));
 
 #ifdef LINUX
+#ifdef I386
+extern int internal_ioemu P((struct tcb *));
+#endif
 extern int internal_clone P((struct tcb *));
 #endif
 extern int internal_fork P((struct tcb *));
diff -urN strace-4.5/io_emu.c strace-4.5mz/io_emu.c
--- strace-4.5/io_emu.c	1970-01-01 01:00:00.000000000 +0100
+++ strace-4.5mz/io_emu.c	2003-11-15 19:07:08.000000000 +0100
@@ -0,0 +1,199 @@
+/*
+ * Copyright (c) 2003 Maciej Zenczykowski <maze@cela.pl>
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. The name of the author may not be used to endorse or promote products
+ *    derived from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ *	$Id: io_emu.c,v 1.00 2003/10/15 17:36:37 maze Exp $
+ */
+
+#include "defs.h"
+
+#if defined(LINUX) && defined(I386)
+
+/*
+#include <stdlib.h>
+#include <string.h>
+#include <stdio.h>
+#include <errno.h>
+#include <unistd.h>
+#include <asm/unistd.h>
+#include <sys/ptrace.h>
+*/
+#include <linux/ptrace.h>
+/*
+#include <sys/types.h>
+#include <sys/resource.h>
+#include <sys/wait.h>
+#include <sys/io.h>
+*/
+
+typedef int bool;
+#define false ((bool)0)
+#define true  ((bool)1)
+
+typedef   signed char   int8;
+typedef   signed short  int16;
+typedef   signed int    int32;
+typedef unsigned char  uint8;
+typedef unsigned short uint16;
+typedef unsigned int   uint32;
+
+struct user_regs {
+  union {
+    struct { uint32 ebx,              ecx,              edx;              };
+    struct { uint16 bx,     xbx,      cx,     xcx,      dx,     xdx;      };
+    struct { uint8  bl, bh, xbl, xbh, cl, ch, xcl, xch, dl, dh, xdl, xdh; };
+  };
+  union {
+    struct { uint32 esi,              edi,              ebp;               };
+    struct { uint16 si,     xsi,      di,     xdi,      bp,     xbp;       };
+  };
+  union {
+    struct { uint32 eax;              };
+    struct { uint16 ax,     xax;      };
+    struct { uint8  al, ah, xal, xah; };
+  };
+  uint16 ds, xds, es, xes, fs, xfs, gs, xgs;
+  union {
+    struct { uint32 _eax,                 eip;     };
+    struct { uint16 _ax,      _xax,       ip, xip; }; 
+    struct { uint8  _al, _ah, _xal, _xah; };
+  };
+  uint16 cs, xcs;
+  union {
+    struct { uint32 eflags,        esp;     };
+    struct { uint16 flags, xflags, sp, xsp; };
+  };
+  uint16 ss, xss;
+};
+
+static inline void out_b (uint16 port, uint8  * v) { asm volatile ("outb\t%b0, %w1" : : "a" (*v), "Nd" (port)); };
+static inline void out_w (uint16 port, uint16 * v) { asm volatile ("outw\t%w0, %w1" : : "a" (*v), "Nd" (port)); };
+static inline void out_l (uint16 port, uint32 * v) { asm volatile ("outl\t%0, %w1"  : : "a" (*v), "Nd" (port)); };
+
+static inline void in_b  (uint16 port, uint8  * v) { asm volatile ("inb\t%w1, %b0"  : "=a" (*v) : "Nd" (port)); };
+static inline void in_w  (uint16 port, uint16 * v) { asm volatile ("inw\t%w1, %w0"  : "=a" (*v) : "Nd" (port)); };
+static inline void in_l  (uint16 port, uint32 * v) { asm volatile ("inl\t%w1, %0"   : "=a" (*v) : "Nd" (port)); };
+
+bool valid_port (struct tcb *tcp, uint16 port, int mask) {
+  if (tcp->iopl == 3) return true;
+  if ( ((*(uint16*)&tcp->io_bitmap[port >> 3]) >> (port & 7)) & mask ) return false;
+  return true;
+};
+#define valid8(P)  valid_port((P), 1)
+#define valid16(P) valid_port((P), 3)
+#define valid32(P) valid_port((P), 7)
+
+uint32 mask[] = { 0, 0xFF, 0xFFFF, 0xFFFFFF, 0xFFFFFFFF };
+
+static int emulate_io (struct tcb *tcp) {
+  struct user_regs regs;
+  ptrace(PTRACE_GETREGS, tcp->pid, 0, (int)&regs);
+  int seg = 0;
+  bool gr1 = 0, gr2 = 0, gr3 = 0, gr4 = 0;
+  bool op32 = 1, ad32 = 1; /* !!! ASSUMES 32BIT CODE !!! */
+  bool lock = 0, repne = 0, repe = 0;
+  int pp = 0;
+  uint8 insn, param;
+  
+loop:
+#define CODE8(P) ((uint8)(ptrace(PTRACE_PEEKTEXT, tcp->pid, (char*)(P), 0)))
+  insn = CODE8(regs.eip + pp); ++pp;
+  param = CODE8(regs.eip + pp);
+
+  switch (insn) {
+#define dprintf(...)
+    case 0x26: dprintf("ES: ");    if (gr1++) goto error; seg = ES; goto loop;
+    case 0x2E: dprintf("CS: ");    if (gr1++) goto error; seg = CS; goto loop;
+    case 0x36: dprintf("SS: ");    if (gr1++) goto error; seg = SS; goto loop;
+    case 0x3E: dprintf("DS: ");    if (gr1++) goto error; seg = DS; goto loop;
+    case 0x64: dprintf("FS: ");    if (gr1++) goto error; seg = FS; goto loop;
+    case 0x65: dprintf("GS: ");    if (gr1++) goto error; seg = GS; goto loop;
+    case 0x66: dprintf("(op32) "); if (gr2++) goto error; op32 ^= 1; goto loop;
+    case 0x67: dprintf("(ad32) "); if (gr3++) goto error; ad32 ^= 1; goto loop;
+    case 0xF0: dprintf("lock "  ); if (gr4++) goto error; lock  = 1; goto loop;
+    case 0xF2: dprintf("repne " ); if (gr4++) goto error; repne = 1; goto loop;
+    case 0xF3: dprintf("rep(e) "); if (gr4++) goto error; repe  = 1; goto loop;
+#undef dprintf
+
+    /* DISABLE/ENABLE INTERRUPTS - IGNORE! */
+    case 0xFA: if (gr1 || gr2 || gr3 || gr4) goto error; tprintf("cli"); goto ok;
+    case 0xFB: if (gr1 || gr2 || gr3 || gr4) goto error; tprintf("sti"); goto ok;
+
+    /* STRING I/O - UNIMPLEMENTED */
+    case 0x6C: if (gr1 || lock || repne) goto error; tprintf("insb"); goto error;
+    case 0x6D: if (gr1 || lock || repne) goto error; tprintf("insw/l"); goto error;
+    case 0x6E: if (       lock || repne) goto error; tprintf("outsb"); goto error;
+    case 0x6F: if (       lock || repne) goto error; tprintf("outsw/l"); goto error;
+
+#define simulate_in(szo, sza, port) \
+tprintf("in%c(0x%0*X) = ", "0bw3l"[szo], sza+sza, port); \
+if (!valid_port(tcp, port, (1 << szo) - 1 )) { tprintf("ERROR"); goto error; }; \
+if (szo == 1) in_b(port, &regs.al); \
+if (szo == 2) in_w(port, &regs.ax); \
+if (szo == 4) in_l(port, &regs.eax); \
+tprintf("0x%0*X", szo+szo, regs.eax & mask[szo]); \
+goto ok;
+
+#define simulate_out(szo, sza, port) \
+tprintf("out%c(0x%0*X, 0x%0*X)", "0bw3l"[szo], sza+sza, port, szo+szo, regs.eax & mask[szo]); \
+if (!valid_port(tcp, port, (1 << szo) - 1 )) { tprintf(" => ERROR"); goto error; }; \
+if (szo == 1) out_b(port, &regs.al); \
+if (szo == 2) out_w(port, &regs.ax); \
+if (szo == 4) out_l(port, &regs.eax); \
+goto ok;
+
+    /* NORMAL I/O */
+    case 0xE4: if (gr1 || gr3 || gr4) goto error; pp++; simulate_in (           1, 1, param);
+    case 0xE5: if (gr1 || gr3 || gr4) goto error; pp++; simulate_in (op32 ? 4 : 2, 1, param);
+    case 0xE6: if (gr1 || gr3 || gr4) goto error; pp++; simulate_out(           1, 1, param);
+    case 0xE7: if (gr1 || gr3 || gr4) goto error; pp++; simulate_out(op32 ? 4 : 2, 1, param);
+    case 0xEC: if (gr1 || gr3 || gr4) goto error;       simulate_in (           1, 2, regs.dx);
+    case 0xED: if (gr1 || gr3 || gr4) goto error;       simulate_in (op32 ? 4 : 2, 2, regs.dx);
+    case 0xEE: if (gr1 || gr3 || gr4) goto error;       simulate_out(           1, 2, regs.dx);
+    case 0xEF: if (gr1 || gr3 || gr4) goto error;       simulate_out(op32 ? 4 : 2, 2, regs.dx);
+
+#undef simulate_out
+#undef simulate_in
+
+    /* ANYTHING ELSE IS BAD */
+    default: goto error;
+  };
+ok:
+  regs.eip += pp;
+  ptrace(PTRACE_SETREGS, tcp->pid, 0, (int)&regs);
+  return pp;
+error:
+  return 0;
+};
+
+int internal_ioemu (struct tcb *tcp) {
+  int res;
+  printleader(tcp);
+  res = emulate_io(tcp);
+  printtrailer(tcp);
+  return res;
+};
+
+#endif
diff -urN strace-4.5/linux/dummy.h strace-4.5mz/linux/dummy.h
--- strace-4.5/linux/dummy.h	2003-06-27 23:20:10.000000000 +0200
+++ strace-4.5mz/linux/dummy.h	2003-11-15 13:28:01.000000000 +0100
@@ -28,10 +28,13 @@
  *	$Id: dummy.h,v 1.12 2003/06/27 21:20:10 roland Exp $
  */
 
-/* still unfinished */
+/* possibly simulated for IO-trace on x86 */
+#ifndef I386
 #define	sys_ioperm		printargs
-#define	sys_syslog		printargs
 #define	sys_iopl		printargs
+#endif
+/* still unfinished */
+#define	sys_syslog		printargs
 #define	sys_vm86old		printargs
 #define	sys_get_kernel_syms	printargs
 #define	sys_bdflush		printargs
diff -urN strace-4.5/Makefile.am strace-4.5mz/Makefile.am
--- strace-4.5/Makefile.am	2003-03-31 02:59:18.000000000 +0200
+++ strace-4.5mz/Makefile.am	2003-11-15 17:38:06.000000000 +0100
@@ -15,7 +15,7 @@
 strace_SOURCES = strace.c syscall.c util.c desc.c file.c ipc.c \
 		 io.c ioctl.c mem.c net.c process.c bjm.c \
 		 resource.c signal.c sock.c system.c term.c time.c \
-		 proc.c stream.c
+		 proc.c stream.c io_emu.c
 noinst_HEADERS = defs.h
 
 EXTRA_DIST = $(man_MANS) errnoent.sh signalent.sh syscallent.sh ioctlsort.c \
diff -urN strace-4.5/strace.c strace-4.5mz/strace.c
--- strace-4.5/strace.c	2003-06-10 05:05:53.000000000 +0200
+++ strace-4.5mz/strace.c	2003-11-15 18:54:55.000000000 +0100
@@ -3,6 +3,7 @@
  * Copyright (c) 1993 Branko Lankester <branko@hacktic.nl>
  * Copyright (c) 1993, 1994, 1995, 1996 Rick Sladkey <jrs@world.std.com>
  * Copyright (c) 1996-1999 Wichert Akkerman <wichert@cistron.nl>
+ * Copyright (c) 2003 Maciej Zenczykowski <maze@cela.pl> Linux x86 IO trace
  * All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
@@ -49,6 +50,10 @@
 # include <asm/ptrace_offsets.h>
 #endif
 
+#if defined(linux) && defined(I386)
+# include <sys/io.h>
+#endif
+
 #ifdef USE_PROCFS
 #include <poll.h>
 #endif
@@ -64,7 +69,7 @@
 
 int debug = 0, followfork = 0, followvfork = 0, interactive = 0;
 int rflag = 0, tflag = 0, dtime = 0, cflag = 0;
-int iflag = 0, xflag = 0, qflag = 0;
+int iflag = 0, ioflag = 0, xflag = 0, qflag = 0;
 int pflag_seen = 0;
 
 /* Sometimes we want to print only succeeding syscalls. */
@@ -133,33 +138,36 @@
 FILE *ofp;
 int exitval;
 {
-	fprintf(ofp, "\
-usage: strace [-dffhiqrtttTvVxx] [-a column] [-e expr] ... [-o file]\n\
-              [-p pid] ... [-s strsize] [-u username] [-E var=val] ...\n\
-              [command [arg ...]]\n\
-   or: strace -c [-e expr] ... [-O overhead] [-S sortby] [-E var=val] ...\n\
-              [command [arg ...]]\n\
--c -- count time, calls, and errors for each syscall and report summary\n\
--f -- follow forks, -ff -- with output into separate files\n\
--F -- attempt to follow vforks, -h -- print help message\n\
--i -- print instruction pointer at time of syscall\n\
--q -- suppress messages about attaching, detaching, etc.\n\
--r -- print relative timestamp, -t -- absolute timestamp, -tt -- with usecs\n\
--T -- print time spent in each syscall, -V -- print version\n\
--v -- verbose mode: print unabbreviated argv, stat, termio[s], etc. args\n\
--x -- print non-ascii strings in hex, -xx -- print all strings in hex\n\
--a column -- alignment COLUMN for printing syscall results (default %d)\n\
--e expr -- a qualifying expression: option=[!]all or option=[!]val1[,val2]...\n\
-   options: trace, abbrev, verbose, raw, signal, read, or write\n\
--o file -- send trace output to FILE instead of stderr\n\
--O overhead -- set overhead for tracing syscalls to OVERHEAD usecs\n\
--p pid -- trace process with process id PID, may be repeated\n\
--s strsize -- limit length of print strings to STRSIZE chars (default %d)\n\
--S sortby -- sort syscall counts by: time, calls, name, nothing (default %s)\n\
--u username -- run command as username handling setuid and/or setgid\n\
--E var=val -- put var=val in the environment for command\n\
--E var -- remove var from the environment for command\n\
-" /* this is broken, so don't document it
+	fprintf(ofp,
+"usage: strace [-dffhiqrtttTvVxx] [-a column] [-e expr] ... [-o file]\n"
+"              [-p pid] ... [-s strsize] [-u username] [-E var=val] ...\n"
+"              [command [arg ...]]\n"
+"   or: strace -c [-e expr] ... [-O overhead] [-S sortby] [-E var=val] ...\n"
+"              [command [arg ...]]\n"
+"-c -- count time, calls, and errors for each syscall and report summary\n"
+"-f -- follow forks, -ff -- with output into separate files\n"
+"-F -- attempt to follow vforks, -h -- print help message\n"
+"-i -- print instruction pointer at time of syscall\n"
+#if defined(LINUX) && defined(I386)
+"-I -- perform IO instruction traceing (experimental, doesn't work with attach/detach)\n"
+#endif
+"-q -- suppress messages about attaching, detaching, etc.\n"
+"-r -- print relative timestamp, -t -- absolute timestamp, -tt -- with usecs\n"
+"-T -- print time spent in each syscall, -V -- print version\n"
+"-v -- verbose mode: print unabbreviated argv, stat, termio[s], etc. args\n"
+"-x -- print non-ascii strings in hex, -xx -- print all strings in hex\n"
+"-a column -- alignment COLUMN for printing syscall results (default %d)\n"
+"-e expr -- a qualifying expression: option=[!]all or option=[!]val1[,val2]...\n"
+"   options: trace, abbrev, verbose, raw, signal, read, or write\n"
+"-o file -- send trace output to FILE instead of stderr\n"
+"-O overhead -- set overhead for tracing syscalls to OVERHEAD usecs\n"
+"-p pid -- trace process with process id PID, may be repeated\n"
+"-s strsize -- limit length of print strings to STRSIZE chars (default %d)\n"
+"-S sortby -- sort syscall counts by: time, calls, name, nothing (default %s)\n"
+"-u username -- run command as username handling setuid and/or setgid\n"
+"-E var=val -- put var=val in the environment for command\n"
+"-E var -- remove var from the environment for command\n"
+ /* this is broken, so don't document it
 -z -- print only succeeding syscalls\n\
   */
 , DEFAULT_ACOLUMN, DEFAULT_STRLEN, DEFAULT_SORTBY);
@@ -205,7 +213,7 @@
 	set_sortby(DEFAULT_SORTBY);
 	set_personality(DEFAULT_PERSONALITY);
 	while ((c = getopt(argc, argv,
-		"+cdfFhiqrtTvVxza:e:o:O:p:s:S:u:E:")) != EOF) {
+		"+cdfFhiIqrtTvVxza:e:o:O:p:s:S:u:E:")) != EOF) {
 		switch (c) {
 		case 'c':
 			cflag++;
@@ -226,6 +234,9 @@
 		case 'i':
 			iflag++;
 			break;
+		case 'I':
+			ioflag++; /* only actually works on I386 */
+			break;
 		case 'q':
 			qflag++;
 			break;
@@ -581,6 +592,14 @@
 	sigaction(SIGCHLD, &sa, NULL);
 #endif /* USE_PROCFS */
 
+#if defined(LINUX) && defined(I386)
+	if (ioflag && iopl(3) < 0) {
+		perror("strace: iopl");
+		cleanup();
+		exit(1);
+	}
+#endif
+
 	if (trace() < 0)
 		exit(1);
 	cleanup();
@@ -630,6 +649,13 @@
 			tcp->nclone_threads = tcp->nclone_detached = 0;
 			tcp->nclone_waiting = 0;
 #endif
+#if defined(LINUX) && defined(I386)
+			tcp->cap_rawio = 1; /*FIXME*/
+			tcp->ioscno = 0;
+			tcp->ioretval = 0;
+			tcp->iopl = 3; /*FIXME_MAZE on fork should inherit*/
+			memset(tcp->io_bitmap, -1, sizeof(tcp->io_bitmap)); /*AS ABOVE*/
+#endif
 			tcp->flags = TCB_INUSE | TCB_STARTUP;
 			tcp->outf = outf; /* Initialise to current out file */
 			tcp->stime.tv_sec = 0;
@@ -2108,6 +2134,19 @@
 				}
 				continue;
 			}
+#if defined (LINUX) && defined (I386)
+			if (ioflag && WSTOPSIG(status) == SIGSEGV) {
+				if (internal_ioemu(tcp)) {
+					if (ptrace(PTRACE_SYSCALL, pid, (char *) 1, 0) < 0) {
+						perror("trace: ptrace(PTRACE_SYSCALL, ...)");
+						cleanup();
+						return -1;
+					}
+				        tcp->flags &= ~TCB_SUSPENDED;
+					continue;
+				}
+			}
+#endif
 			if (!cflag
 			    && (qual_flags[WSTOPSIG(status)] & QUAL_SIGNAL)) {
 				unsigned long addr = 0, pc = 0;
diff -urN strace-4.5/syscall.c strace-4.5mz/syscall.c
--- strace-4.5/syscall.c	2003-09-25 00:22:41.000000000 +0200
+++ strace-4.5mz/syscall.c	2003-11-15 17:39:09.000000000 +0100
@@ -6,6 +6,7 @@
  * Copyright (c) 1999 IBM Deutschland Entwicklung GmbH, IBM Corporation
  *                     Linux for s390 port by D.J. Barrow
  *                    <barrow_dj@mail.yahoo.com,djbarrow@de.ibm.com>
+ * Copyright (c) 2003 Maciej Zenczykowski <maze@cela.pl> Linux x86 IO trace
  * All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
@@ -2111,6 +2112,14 @@
 	if (res != 1)
 		return res;
 
+#if defined(LINUX) && defined(I386)
+	if (tcp->ioscno) {
+		tcp->scno = tcp->ioscno;
+		tcp->ioscno = 0;
+		force_result(tcp, 0, tcp->ioretval);
+	}
+#endif
+
 	if (tcp->flags & TCB_INSYSCALL) {
 		long u_error;
 		res = get_error(tcp);
@@ -2161,7 +2170,7 @@
 			tcp->flags &= ~TCB_INSYSCALL;
 			return 0;
 		}
-
+		
 		if (tcp->scno >= nsyscalls || tcp->scno < 0
 		    || (qual_flags[tcp->scno] & QUAL_RAW))
 			sys_res = printargs(tcp);
@@ -2413,6 +2422,61 @@
 	return 0;
 }
 
+#if defined(LINUX) && defined(I386)
+int
+sys_iopl(tcp)
+struct tcb *tcp;
+{
+	printargs(tcp);
+	if (ioflag && !(tcp->flags & TCB_INSYSCALL) ) {
+		int res; unsigned level = tcp->u_arg[0];
+		
+		res = -EINVAL;
+		if (level > 3) goto out;
+		/* Trying to gain more privileges? */
+		res = -EPERM;
+		if (level > tcp->iopl) if (!tcp->cap_rawio) goto out;
+		res = 0;
+		tcp->iopl = level;
+	    out:
+		tcp->ioretval = res;
+		tcp->ioscno = tcp->scno;
+		/* ignore the syscall */
+		tcp->scno = 0;
+		ptrace(PTRACE_POKEUSER, tcp->pid, (char*)(4*ORIG_EAX), 0);
+	}
+	return 0;
+}
+
+int
+sys_ioperm(tcp)
+struct tcb *tcp;
+{
+	printargs(tcp);
+	if (ioflag && !(tcp->flags & TCB_INSYSCALL) ) {
+		int res, i;
+		unsigned from = tcp->u_arg[0], num = tcp->u_arg[1], turn_on = tcp->u_arg[2];
+		res = -EINVAL;
+		if ((from + num <= from) || (from + num > MAX_IOPERM)) goto out;
+		res = -EPERM;
+		if (turn_on && !tcp->cap_rawio) goto out;
+
+		res = 0; /* doesn't have to be fast */
+		for (i = from; i < from + num; i++) {
+			if (turn_on) tcp->io_bitmap[i >> 3] &= ~( 1 << (i & 7) );
+			else         tcp->io_bitmap[i >> 3] |=  ( 1 << (i & 7) );
+		};
+	    out:
+		tcp->ioretval = res;
+	        tcp->ioscno = tcp->scno;
+	        /* ignore the syscall */
+		tcp->scno = 0;
+	        ptrace(PTRACE_POKEUSER, tcp->pid, (char*)(4*ORIG_EAX), 0);
+	}
+	return 0;
+}
+#endif
+
 long
 getrval2(tcp)
 struct tcb *tcp;

Re: Announce: ndiswrapper

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1013 bytes --]

On Tue, 2003-11-18 15:14:01 +0100, Maciej Zenczykowski <maze@cela.pl>
wrote in message <Pine.LNX.4.44.0311181510290.29639-100000@gaia.cela.pl>:
> > 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       jbglaw@lug-owl.de    . +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));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Announce: ndiswrapper

[Davide Libenzi]

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

Re: Announce: ndiswrapper

[Richard B. Johnson]

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.

Re: Announce: ndiswrapper

[Maciej Zenczykowski]

> 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.

Re: Announce: ndiswrapper

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 258 bytes --]

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 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Announce: ndiswrapper

[Jeff Garzik]

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

Re: Announce: ndiswrapper

[Richard B. Johnson]

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.

Re: Announce: ndiswrapper

[Christian Axelsson]

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
smiler@lanil.mine.nu

Re: Announce: ndiswrapper

[Maciej Zenczykowski]

> 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.

Re: Announce: ndiswrapper

[Christian Axelsson]

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
smiler@lanil.mine.nu

Announce: ndiswrapper

[Pontus Fuchs]

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