Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Wireless Networking Software Hardware Linux

NDIS Wrapper For Wireless LAN Cards Under GPL 222

Posted by timothy from the subvert-the-cooption-and-vice-versa dept.
An anonymous reader writes " Shortly after Linuxant has released their commercial DriverLoader, Pontus Fuchs has made an NDIS wrapper available under the GPL. Since some vendors refuse to release specifications or even a binary Linux-driver for their Wireless LAN cards he has decided to solve it himself by making a kernel module that can load Microsoft-Windows NDIS drivers. ndiswrapper has been tested with some BroadCom miniPCI cards and it seems to work on some laptops . With some more work it should be possible to support more cards. Hopefully this will be the case for the many owners of Linux laptops based on Intel's Centrino technology. Please contact Pontus if you are interested in helping out!"
This discussion has been archived. No new comments can be posted.

NDIS Wrapper For Wireless LAN Cards Under GPL More

NDIS Wrapper For Wireless LAN Cards Under GPL

Comments Filter:

  • What, no screen shots?? (Score:5, Funny)

    by rvaniwaa ( 136502 ) * on Wednesday November 19, 2003 @12:37PM (#7511959) Homepage
    How does he expect people to try out his code without any screen shots????

  • Sweet! (Score:2, Interesting)

    by zx-6e ( 604380 )
    As long as the NDIS wrappers support all the capabilities of the cards, this is great news!

    • Re:Sweet! (Score:3, Informative)

      by Anonymous Coward
      An NDIS driver provides functionality to make the card work. Its a standard way to operate with the card from a program if you dont know a particular card's interface. So no, NDIS does NOT support all the capacilities of the card as far as alternate forms of authentication and the little extra goodies the manufactorer puts in. But, it will get the card working with its basic functions which is better then not working at all.

  • Not the best solution (Score:3, Insightful)

    by mocm ( 141920 ) on Wednesday November 19, 2003 @12:40PM (#7511984)
    compared to a native driver, but certainly helpful in reverse engineering the windows drivers.

  • Support supported cards (Score:4, Interesting)

    by Neil Watson ( 60859 ) on Wednesday November 19, 2003 @12:41PM (#7511985) Homepage
    Would someone care to point out which cards have native Linux drivers available? Once we have this list I think we should go out of our way to buy from vendors with Linux drivers.

    • That's Easy (Score:5, Informative)

      by OctaneZ ( 73357 ) <ben-slashdot2NO@SPAMuma.litech.org> on Wednesday November 19, 2003 @12:44PM (#7512011) Journal
      Here's a nice list at HP [hp.com] of cards that work.

    • Re:Support supported cards (Score:4, Informative)

      by pyros ( 61399 ) on Wednesday November 19, 2003 @01:15PM (#7512238) Journal
      cards besed on the prism chipset and the orinnoco/hermes chipset(s) work very well. Cisco aironet cards have worked pretty well for me, too. I think the big stinkers are the broadcom based ones.

      • Re:Support supported cards (Score:4, Informative)

        by Kamel Jockey ( 409856 ) on Wednesday November 19, 2003 @02:07PM (#7512755) Homepage

        Likewise, I've also been able to use the Linux-WLAN-NG [linux-wlan.com] drivers to make various wireless adapters work under Redhat Linux versions 7.2 and 9. The devices that I have actually used successfully are:

        • Proxim RangeLan-DS PC Card (oddly enough I can't get this card to work under Windows 98 or XP)
        • Linksys WPC-11 v.3 PC Card
        • Microsoft(!) MN-510 USB wireless adapter (works pretty well with Kismet [kismetwireless.net])

        I noticed that the README file included in the download mentioned a "BroadCom" wireless card. I'm curious as to whether or not this is the newer Linksys PCI wireless card (WMP11) which used to work with Linux-WLAN-NG before they changed the friggin' chipset from Prism2 to Broadcom.

        • yeah, I have a WPC-11, and I've been very happy with it. I finally got encryption (albeit 64bit) working with the orinoco_cs driver, which means I don't have to wait for this guy [raleigh.nc.us] to catch up with new kernel releases. I'm pretty sure that Linksys switched to Broadcom. That's actually part of the big stink over the source code for the WRT54G [linksys.com] router they sell. It runs linux, and uses a Broadcom chipset. So we know a driver exists.

          • finally got encryption (albeit 64bit) working with the orinoco_cs driver

            I was able to get 128-bit encryption to work with the Linux-Wlan-NG Prism2 driver with the WPC-11 and the Proxim cards. It was just a settings change in the one config file they provide for you.

          • Microsoft(!) MN-510 USB wireless adapter (works pretty well with Kismet)

          As much as it makes me feel dirty, I just bought a Microsoft MN-520 card, and it works beautifully (WEP and all) with the orinoco_cs driver. I looked high and low for another card that I could buy locally (in order avoid waiting for delivery, dealing with potential returns, etc) that had documented linux support, and this was the only one I could find (Office Max). Other locally-available cards were all based on chipsets that aren'

    • I bought 2 PCI Linksys WMP11 cards last week at Walmart. While I was standing in the store looking at them I was relatively sure that I remembered that that card had Linux support. (Both cards had the same model # but appeared to be two slightly different cards.) I thought that was strange and since I wasn't 100% sure if they would work with Linux I decided I better do some research before opening the packages. I found out that only certain variations of the Linksys WMP11 card is supported with Linux.

  • Double edged sword (Score:5, Insightful)

    by Mr Bill ( 21249 ) on Wednesday November 19, 2003 @12:42PM (#7511992)
    This is kind of a double edged sword. Now that you can use NDIS drivers under Linux, it will be that much harder to convince these companies that providing a native Linux driver would be good for their business...

    If you are in the market for one of these cards, buy from a company that supports your OS of choice...

    • Re:Double edged sword (Score:5, Insightful)

      by nbvb ( 32836 ) on Wednesday November 19, 2003 @12:51PM (#7512069) Journal
      Heh, this sounds like the OS/2 problem:

      We make a better DOS than DOS, and a better Windows than Windows!

      So who'd bother writing for OS/2 when I can just write for Win or DOS?

      • Re:Double edged sword (Score:2, Insightful)

        by Lussarn ( 105276 )
        Except that very few companies write for Linux anyway. Of course, very few wrote for OS/2 too but linux have a much stronger community than OS/2 ever had.

        We don't even want closed source binary drivers. We want the specs for the hardware.

        I don't think there ever was a OS/2 problem as it is described. Noone wrote for BeOS either and BeOS didn't have ANY apps. Surely it's better to run windows apps than nothing.
      • That's often mentioned as an argument against a competitor's legacy systems, it's more complex than that. Linux and OS/2 are substantially different.

        Back when IBM attempted to push OS/2 to the buying public, it was a $100+ product, while DOS/Windows was "free" (it seemed free from the end-user perspective, in that it came with every computer and customers couldn't reduce PC cost by declining DOS)

        Today, however, Linux is a $0 product, and some buyers now have the option of bare-bones systems where Windows

      • Re:Double edged sword (Score:4, Insightful)

        by PCM2 ( 4486 ) on Wednesday November 19, 2003 @01:47PM (#7512520) Homepage
        Well, a counter-example might be Mac OS X. You could write apps for OS 9 and they would run in Classic mode. Or, you could code to the Carbon libraries and your apps should work on both OS 9 and OS X. Or, you could write your apps to the Cocoa frameworks, and they'll only work on OS X, yet they'll be "better."

        Seems to me that, while the initial reaction was to code to Carbon, most brand-new applications being written (or rewritten) for OS X these days are Cocoa applications.

        It's not the same thing as the OS/2 example, exactly, because Apple controls both the Carbon and Cocoa libraries and has pretty much announced the death of OS 9, so backward compatibility is not an issue. But if you consider that even established Mac OS developers have begun coding to Cocoa in spite of their past investments in Carbon/Mac OS 7-9.x development, it seems that some vendors, at least, are capable of seeing the value in doing something the "better" way, rather than just sticking to what they know.

        Where hardware vendors and Linux drivers are concerned, we'll just have to wait and see. This seems like a case where everybody really should hope Linux gets "ready for the desktop" -- because a couple million laptops out there running Linux as a primary OS are going to convince the hardware manufacturers a lot more quickly than a bunch of servers will.
      • the more users you can get running Linux the more likely the manufacturers will be interested in your platform. a user will choose the product that works best on her platform; i'm assuming native driver would be better than an NDIS wrapper.

        i agree with the other poster that we don't want binary only drivers but if the alternative is windows (binary) or no driver i guess i'll make concessions.

        what incentive do manufacturers have for open sourcing their drivers?

    • This is kind of a double edged sword. Now that you can use NDIS drivers under Linux, it will be that much harder to convince these companies that providing a native Linux driver would be good for their business...

      If you are in the market for one of these cards, buy from a company that supports your OS of choice...

      I completely agree. It's quite obvious that tech is about market share and mind share--gettimg everyone to adopt your product. If people buy your product, you are doing sowething right. I

    • Re:Double edged sword (Score:5, Insightful)

      by Minna Kirai ( 624281 ) on Wednesday November 19, 2003 @01:31PM (#7512361)
      This is kind of a double edged sword.

      That's the same argument that comes up around Wine, or other projects that allow non-native applications to run on a platform- backward compatibility might discourage creation of true native apps.

      It's a valid concern. But for the position Linux is in today, it looks like a degree of Windows compatibility will help more than it hurts.

      If two systems can share binary applications and drivers, then a barrier for users to switch between those systems has been reduced. Compatibility might encourage switching in either direction- but the rule of thumb is that lowered switching costs helps minority solutions increase their popularity.

      Virtually everyone uses Windows(r)... if switching to other things were easier, then more people will switch, and the number of Linux installs will increase.

      If you are in the market for one of these cards, buy from a company that supports your OS of choice...

      One way a company might "support" linux is by including this wrapper module with the hardware, and pointing Linux customers to instructions on how to use it. This way, hardware vendors can take a gentle slope towards native Linux support: their initial investment in software programming is minimized, but they can get accustomed to the idea that some of their customers are buying for Linux, and that the platform deserves support in the future.
    • You know, that agrument comes up every time a compatibility layer is announced here... and I disagree. A third-party driver wrapper will never offer the same level of convenience or (more importantly) support that a fully supported driver has. Any suggestion by the hardware vendor that their big customers use such a wrapper instead of a properly supported driver will therefore not hold water. The customers can still very reasonably threaten to take their business elsewhere, and the vendor will still have

  • Wrapper should send e-mail to hardware vendor (Score:5, Interesting)

    by Anonymous Coward on Wednesday November 19, 2003 @12:43PM (#7511995)
    The wrapper should send an e-mail to the hardware vendor every time it loads. As more people use the wrapper, they get more and more e-mail. Perhaps they would rather write proper Linux drivers than get more e-mail. ;-)

  • Cross Platform Drivers (Score:4, Interesting)

    by AKAImBatman ( 238306 ) <akaimbatman@gmaiBLUEl.com minus berry> on Wednesday November 19, 2003 @12:47PM (#7512038) Homepage Journal
    For quite a while now, I've considered what sorts of problems would be inherent in cross platform drivers. Usually, the problem seems to come back to a difference in the way kernels manage their drivers and differences in the way that I/O is done between OSes. Perhaps a "Driver Adapter" could be built that would allow drivers written for it to run on any OS? The basic concept is that the adapter itself would be a driver for the OS, then the "Cross Platform Drivers" would deal directly with the adapter.

    Anyone have any thoughts on why this would or wouldn't work?

    • Anyone have any thoughts on why this would or wouldn't work?

      Because there's absolutely no business reason why Microsoft would care to support such a standard? And if Microsoft isn't on board, it is just an academic exercise with very little real world value?

      • > Because there's absolutely no business reason why
        > Microsoft would care to support such a standard?

        The adapter I'm describing requires nothing from the OS vendor. Yes, someone will still have to code the OS specific adapter code, but that's not necessarily the vendor. Once completed, the adapter would plug in like a normal driver and all Cross Platform drivers would plug into the adapter.

        • The adapter I'm describing requires nothing from the OS vendor. Yes, someone will still have to code the OS specific adapter code, but that's not necessarily the vendor. Once completed, the adapter would plug in like a normal driver and all Cross Platform drivers would plug into the adapter.

          If Microsoft doesn't support the driver model, none of the current Windows IHVs will either.

          • > If Microsoft doesn't support the driver model, none of the
            > current Windows IHVs will either.

            That depends on how much cross platform support is worth to them. If the ability to release the same driver for Window, Linux, and FreeBSD exists, and you need support for multiple platforms to compete, why not use it? Not to mention that it would simplify porting between Windows versions. Right now, IHVs are screwed over every time Microsoft releases a new version of Windows. Now, instead of going back and
    • NDIS is a cross-platform network driver model, or at least it was when I worked with it ~10 years ago. An NDIS driver never calls the OS directly; everything goes through the NDIS wrapper, thus providing an abstraction layer over the actual OS.

      Now, if someone will just write a similar layer for Linux that can load Windows NT filesystem drivers, then I can get read/write access to my NTFS partitions... Hmm...
      • > NDIS is a cross-platform network driver model, or at
        > least it was when I worked with it ~10 years ago.

        Are we talking about the same NDIS? The info page describes NDIS as a DLL loader and Windows driver interface. There's nothing there to indicate that it's based on a standard that was around since before Windows 95.

        • The original NDIS specification predates Windows NT, 95, et al. It was, in fact, targeted at DOS and OS/2. A little Googling [see this [microsoft.com], this [pcausa.com], and this [student.fsb.hr]] shows that it has a long (if not glorious) history. IIRC, NDIS binaries would load unmodified in Win NT and Win 95. This is pretty cool given these two OS's vastly different I/O models.
          • Interesting. In that case, should I be blaming Linus for not supporting an industry "standard" in the first place? Or is it as much a moving target as other Microsoft standards?

            Although, I do blame Linus for his poor decision to make kernel drivers version specific...

      • Now, if someone will just write a similar layer for Linux that can load Windows NT filesystem drivers, then I can get read/write access to my NTFS partitions... Hmm...

        Jan Kratchovil has some software which does exactly this: Captive-NTFS [jankratochvil.net].
    • And it died... Two years ago. Lots of talk and no work.
    • There is such a beast, or at least pretty close. It's I2O. According to what I've read, it's a drivers where the OS writes the high-level driver, for their specific OS, and the device maker writes the low level driver that provides functionality to the high level driver. The low level driver can be plugged into any OS. There is a specification for each major type of hardware.

      Here is a link [reference.com] to a page about it.

      It's a neat idea, but I'm not sure how popular it is with hardware makers, and it somewhat c

  • This is not necessarily good news (Score:5, Interesting)

    by Rosco P. Coltrane ( 209368 ) on Wednesday November 19, 2003 @12:48PM (#7512042)
    Good news : I can get that %^*@$# network card going now.

    Bad news : Nobody will bother to write Linux drivers soon enough, they'll all say "why bother, we'll just make a Windows driver and tell people to use the wrapper.

    Net results :

    - This makes card vendors inclined to think only the Windows platform is truly important

    - This allows Microsoft to have the option of one day changing, subtly messing up or adding undocumented calls to their API, slowly leaving Linux people in the cold as all card vendors transition.

    - I would think native drivers are faster / more efficient / more full featured than drivers running under emulation. That might not be the case though, but more often than not, running alien binaries in any OS isn't known to be as fast as the real McCoy.

    • Re:This is not necessarily good news (Score:5, Interesting)

      by arth1 ( 260657 ) on Wednesday November 19, 2003 @01:04PM (#7512160) Homepage Journal

      Bad news : Nobody will bother to write Linux drivers soon enough, they'll all say "why bother, we'll just make a Windows driver and tell people to use the wrapper.


      This is already happening. The excellent 3COM 990 series (the network cards with a RISC CPU and memory on the card), for example, have their own firmware and API that hugely simplified writing a wrapper for Linux, to the point that there isn't a real driver. While the wrapper-drivers work, you don't get the benefits of CPU offloading and profiling that you get under Windows 2000.

      Regards,
      --
      *Art

  • Platform independent drivers (Score:4, Informative)

    by cant_get_a_good_nick ( 172131 ) on Wednesday November 19, 2003 @12:49PM (#7512048)
    This wrapper sounds a bit like the UDI Project [project-udi.org] creates a universally consistent driver DDI across all platforms. All drivers are source code compatible for all platforms with an environment. Drivers are binary compatible between platforms with a common C ABI.

    Unfortunately Caldera was the main weight behind this, back when they actually did something silly like write code to make money instead of sue. They fell on hard times and essentially pulled support, and it's been dead in the water since.

  • Licensing issues (Score:3, Interesting)

    by sgf ( 1581 ) on Wednesday November 19, 2003 @12:55PM (#7512095) Homepage
    How does the licensing work with this? If it's GPL, isn't it being linked (albeit in a kind of weird runtime way) with proprietary code? It seems a nice idea to write code in order to export the features of proprietary code into open software, but how do you distinguish it from programs that do the opposite?
    • How does the licensing work with this? If it's GPL, isn't it being linked (albeit in a kind of weird runtime way) with proprietary code?

      It works the same way as when you make proprietary programs that link to GPL libraries, i.e. it's not legally totally clear that you can, but so far it's an accepted view that dynamically linking isn't quite the same as statically linking GPL code in yours.

      At least that's how I understand the GPL/non-GPL dynamic library linking debate that's been going on for years.

    • Re:Licensing issues (Score:2, Insightful)

      by mrroach ( 164090 )
      Because the GPL is only a distribution license. The user can link against whatever they want. That's why proprietary kernel modules are ok.

      -Mark

  • Kernel space? (Score:3, Insightful)

    by 42forty-two42 ( 532340 ) <bdonlan@g m a i l . c om> on Wednesday November 19, 2003 @12:59PM (#7512118) Homepage Journal
    Is this implemented in kernel space still? Is it possible to implement a driver wrapper like this in Ring 3, or at least in Ring 1 or 2, thus reducing the effects of a driver crash, instead of Ring 0?

  • Next step: integrate with Windows Update (Score:4, Insightful)

    by mentin ( 202456 ) on Wednesday November 19, 2003 @01:04PM (#7512161)
    I can see that soon this will go to Windows Update to find new or updated NDIS drivers.

    Looks like more and more Linux is simply emulating Windows. But if you run Windows drivers and Windows programs via appropriate emulation layers, why not simply run Windows?

    • >why not simply run Windows?

      Same is true with Wine or running Cygwin under Windows. If the market is one controlled by a monopoly then its up to the users to create interoperable solutions. Plain and simple. This kind of "the sky is falling" attitude is a good way to further marginalize Linux.

      In the real wold computers and software have to work with each other thus Wine, Samba, etc. Its only in the fantasy world of fanboys that these things could ever be percieved as bad ideas.

    • If Microsoft did that, they'd have a pile of pissed off companies that would have to re-write their drivers. They'd only be able to make additions, not changes to the API, and then you still have the current versions of the drivers that still use the NDIS API.

    • But if you run Windows drivers and Windows programs via appropriate emulation layers, why not simply run Windows?

      Uh, because if I run Linux I can then run, like, anything else. Duh.

  • one bad thing (Score:3, Interesting)

    by termos ( 634980 ) on Wednesday November 19, 2003 @01:09PM (#7512196) Homepage
    The only bad thing I experienced when testing this NdisWrapper was that I needed Linux 2.6.0-test8 or higher.

    I don't want to run a beta version of Linux, so is there any good reason for this?

  • The reason that this is required: Interference (Score:5, Insightful)

    by Karora ( 214807 ) on Wednesday November 19, 2003 @01:10PM (#7512204) Homepage

    There are people here claiming that we'll never see Linux drivers because of this.

    The main reason this is required, however, is because the latest chipsets for wireless give too much control to the software. That means the user can theoretically control transmit levels and frequencies, and make their transmission interfere with other people's communication.

    Since the transmit power levels and frequencies are all set differently in different parts of the world, the closed-source software is needed to restrict people's control over the hardware.

    And that is a real bummer. It is hard to support closed-source Linux drivers - people don't particularly like them, there are thousands of different kernels out there (each distribution has about fifty or so current at any one time, not to mention all the patches you can download from kernel.org).

    As a result, this doesn't surprise me at all. I think it's probably the only way modern WiFi will be supported under Linux. That doesn't translate to the end of the world, however, since the regulatory situation is quite different for almost everything else in the computer.

    • Re:The reason that this is required: Interference (Score:5, Interesting)

      by fishbowl ( 7759 ) on Wednesday November 19, 2003 @01:22PM (#7512300)
      "Since the transmit power levels and frequencies are all set differently in different parts of the world, the closed-source software is needed to restrict people's control over the hardware. "

      It's a matter of opinion that "restricting people's control over the hardware" is necessary or appropriate. If there is some compelling state interest, then it should be considered a defective and/or dangerous product, which ought to be dispensable only to licensed purchasers.

      Treating it as a problem that the consumer owns does not solve the problem. Just because the manufacturer hasn't enabled the consumer to alter the card's programming, doesn't change the fact that the dangerous device has been distributed into the wild.

      As soon as some independent party (not subject to the US law-by-agency-order), creates software to unlock these cards, the disabled-by-obscurity features will be open. If that's a problem for the state, then they should have considered it before allowing the product to be sold.

      If some product can be converted to a weapon, the fact is, the weapon is in the consumer's hands whether you've told him how to convert it or not. You hold some of the responsibility for this product getting into the consumer's hands.

      • That's a nice fantasy.

        It's a matter of opinion that "restricting people's control over the hardware" is necessary or appropriate.

        No, it's a matter of law and economics.

        Look, in most parts of the US (all?) you're not allowed to make significant modifications to your own house without getting a license. You CAN do it. You MAY NOT do it.

        In most of the world, you're not allowed to broadcast on various frequencies. In much of the world you're not allowed to broadcast at all.

        But there are plenty of cons
        • Lets take your analogy back to linux:

          Ford sells you a car without telling you how to operate it, and only lets a Ford driver supplied with the car drive it.... Just because some people might kill their neighbour if they knew how to operate it themselves.

          Jeroen
          • No, Ford sells you a car with a manual that tells you what it needs - like gas and oil and all those good things. And they ONLY sell you a car if you have a license, and insurance. We call these things "requirements".

            Just like hardware vendors sell you cards with requirements - like a computer, an OS, and all those good things.

            Just as your Ford doen't run if you put milk in the tank, their hardware won't run without Windows on the Computer.

            If the hardware vendor doesn't specify what OS is required, try
            • No, Ford sells you a car with a manual that tells you what it needs - like gas and oil and all those good things. And they ONLY sell you a car if you have a license, and insurance. We call these things "requirements".

              I don't know what country you live in, but here (The Netherlands) you can buy a car without any of that.... The manufacturer would just sell you a car. If you wan't to drive on the road then the government comes in with restrictions.
              Its the same with wireless stuff, you can buy the equipmen
              • "I don't know what country you live in, but here (The Netherlands) you can buy a car without any of that...."

                It's that way in the US too. You won't be able to secure *financing* without a drivers' license and insurance most likely, but that's not really a requirement for owning a car. I owned a car when I was 15, before I had a drivers license. I couldn't drive it on the road except on farm business (specific exemption for moving feed and equipment from one part of your farm to another), but no problem,
              • They actually have two sets of requirements: one set for the actual hardware (such as a 32bit pccard interface) and one for their software (monopolyOS X.y). My computer fits the first set, there is no reason for them to deny me the use of the hardware.

                Fortunately, you live in the Netherleands, where they'll sell you cars you're not able (allowed) to drive. Similarly, they'll sell you hardware you're not able to use.

                All they would have to do is make specs available, they should have documentation for in
            • "It doesn't make sense for them to cater to a vanishingly small percentage of the marketplace."

              But the effect is to increase the monopoly position of Microsoft. I don't care about economics or regulations. The thing I notice is that there are NO 802.11g devices for Linux, BSD, or any other OS, available AT ALL. I interpret this as an intentional leveraged attack on competitors to Microsoft.

              • But the effect is to increase the monopoly position of Microsoft. I don't care about economics or regulations.

                Let me give you a little clue: 3rd party hardware vendors love the monopoly. They only need to develop one set of drivers to sell to 90%+ of the marketplace.

                The thing I notice is that there are NO 802.11g devices for Linux, BSD, or any other OS, available AT ALL.

                A little cut&paste from the apple store:
                "The new PowerBook G4s feature the hot new AirPort Extreme technology, based on the 80
                • I'm seeing a bigger picture than you are.

                  You're just looking at the economics. I'm looking at the cultural implications of, say,
                  linux having no wireless capabilities.

                  If the video card folks did this, and we had no graphics, that would pretty much kill any notions of "linux on the desktop" would it not?

                  Do I think the manufactures have any responsibility to "the culture?" No. But it surprises me that nobody in some free country has simply released a reverse-engineered driver for, say, broadcom chips, in
                  • Shutting out linux from the world of wireless networking might be an unintended consequence of economics,

                    You still do not get it. Nobody is shutting out linux. You want something for free. You don't get it. If you PAY for a driver, one will be available. All the windows users pay for their driver - you just close your eyes to the software they get because it does you no good (until now).

                    but I don't understand how that knowledge is supposed to help me.

                    A prayer you might consider:
                    "God, grant me the
                    • I don't want anything for free. I want the hardware I paid for, to work. It's that simple. If it doesn't work, that's not my fault.

                      I realize that I shouldn't expect hardware to work under linux, and I understand the issues.
                      But, people still seem to be wondering what keeps other OS's from gaining widespread adoption, and I'm saying, here is the answer.

                      I assure you if the situation were the same with video cards or SCSI controllers, as it is with wireless network cards, there would be a whole lot more no
                    • I don't want anything for free. I want the hardware I paid for, to work. It's that simple. If it doesn't work, that's not my fault.

                      Right. And I want my car to run on H2O. If it doesn't, that's not my fault, right? You're asking the same damn thing.

                      But, people still seem to be wondering what keeps other OS's from gaining widespread adoption, and I'm saying, here is the answer.

                      I don't think anyone wonders. I don't - do you?

                      I assure you if the situation were the same with video cards or SCSI con

                  • Re:The reason that this is required: Interference (Score:4, Interesting)

                    by Asmodeus ( 10868 ) on Wednesday November 19, 2003 @05:15PM (#7514756)
                    Its actually quite hard to reverse engineer modern hardware. Gone are the days of a few bits to twiddle on an IO port. Now we are talking entire protocol stacks for complex protocols with varying amounts of the stack and/or compression implemented in hardware. Go read the USB or 802.11 specs sometime. This is not your grandfathers' serial port. Yes, I am experienced at writing device drivers. I reverse engineered a major USB webcam chipset for Linux, and I've written many older drivers.

      • It's a matter of opinion that "restricting people's control over the hardware" is necessary or appropriate. If there is some compelling state interest, then it should be considered a defective and/or dangerous product, which ought to be dispensable only to licensed purchasers.

        Right.

        In this case it is the opinion of the Federal Communications Commission. They have decided not to license these devices for consumer use unless these sorts of controls are in place. Meanwhile the "control in software" appro

    • This is an unfortunate side-effect of the FCC regulations (not that I'm saying to abolish them).

      From the hardware vendor's point of view, it makes the most sense to make a generic, software programmable transmission device. This way, they need only one hardware design for the entire world, just different drivers (although they won't tell you that, of course).

      Imagine how much this stuff would cost if they actually put the limits in the hardware itself (R&D would be insanely expensive). Perhaps some s
    • Since the transmit power levels and frequencies are all set differently in different parts of the world, the closed-source software is needed to restrict people's control over the hardware.

      How does not giving out the source "restrict people's control over the hardware"? Finding out where parameters like power levels and frequencies are stored is usually quite simple, with source or without. In many cases, all you need to do is compare two different versions of the driver.

      People who rely on keeping sour
    • What a load of drivel. It makes no difference whether you have source or now.

      Rich.

  • Even though this code is for Linux, it would be better if it were licensed under an MIT or similar license. That way, it could be incorporated into many non-Windows operating systems, from Linux to NetBSD.

  • We also need... (Score:3)

    by jmv ( 93421 ) on Wednesday November 19, 2003 @01:12PM (#7512222) Homepage
    A stable Linux driver API/ABI. This is getting ridiculous. Windows drivers compiled for a 5 year-old version still work on the current version (maybe a slight exageration), while a driver compiled for 2.4.21 won't work with 2.4.22. Not only that, but even with the same version, driver compatibility depends on SMP option, highmem, ...
    • ...driver compatibility depends on SMP option...

      Well, if you want spinlocks bogging down your uniprocessor kernel go right ahead, but I'd prefer not to.
      • Like it's going to make that much of a difference. BTW, the preempable kernel patch (included in 2.6) now requires SMP locking even on uniprocessors, so big deal.
    • Only binary-only drivers need that kind of ABI stability... The rest of the world has no problems at all....
      A five year old ABI might be nice but you are also dragging five year old mistakes along.

      Jeroen

      • Re:We also need... (Score:3, Insightful)

        by jmv ( 93421 )
        I'm not saying the ABI should be frozen for 5 years, but I think every it shouldn't with micro version numbers. The same driver should work for all of 2.4.x. Now, I know most drivers have source code with them, but sometimes a binary is just much simpler. I mean I can also have the source for XFree86 and OpenOffice, yet I'd rather just get the binaries.
        • The drivers are in fact portable across all 2.4 versions. However, you have to compile the kernel without versioning (which no distro does that I know of by default), which sort of defeats the purpose of that.
          You'd have to build it yourself, then you can play with knives.
          But then, it's probably safer if people can't force load older drivers...sometimes a bugfix the changes the semantics of some kernel function or depricates one, even if all the other APIs are the same.
          The driver shouldn't still be using it
  • .. if "written for other OS" can be interpreted as "copy protection" so something like this can be stopped under DMCA.

  • PowerPC (Score:3, Insightful)

    by O ( 90420 ) on Wednesday November 19, 2003 @02:17PM (#7512852)
    If this works, then no one will bother developing an open source driver, which means there is still no hope for using Airport Extreme, which uses the Broadcom chipset, under Linux on a PowerBook. =(

  • Ask Intel (Score:2, Informative)

    by jwr ( 20994 )
    Or better, contact Intel and ask them, why in spite of all the hype and marketing announcements about them supporting Linux, they have silently failed to deliver either Centrino drivers or Centrino documentation.

    Frankly, I'm rather surprised that no Linux company has sued them yet, for unfair competition. Disclosing drivers and documentation to one OS maker and hiding it from the others IS unfair competition.

Slashdot Top Deals

In the long run, every program becomes rococco, and then rubble. -- Alan Perlis

Close