Migrating Device Drivers to the 2.6 Kernel
An anonymous reader writes "While it's all well and good to find out how to upgrade your kernel to 2.6, as this recent /. story pointed out, developers, especially device driver developers, might be more interested in the kernel's new device driver model. Over at Linux Devices, there's a new article on Migrating device drivers to Linux kernel 2.6. The short version: That little ole Hello, World! kernel module is a heckuva lot more complicated than it used to be."
how is the extra added line of MODULE_LICENCE("x"); make the simple sided 2.6 kernel module substantially more complicated?
.
One of the good things about Microsoft Windows is that is you've written a driver for Windows 98's to the WDM standard, it's still pretty much supported under Windows 2000 and Windows XP. That is to say that there isn't a lot of retrofitting that needs to be done to get a legacy driver working under the latest Microsoft OS.
.EXE can run under Windows 95, 98, 2K and XP and most of the time, it's just going to work. You can't say the same about versions of Linux.
Linux, on the other hand, seems to think it's OK to make developers retrofit their code when they don't like the ad hoc design that the OS contributors came up with. This coupled with issues (questions?) of compatibility with things like the GNU C runtime libraries really must make it frustrating to do any serious development on Linux. (Feel free to rebut--it's been a long time since I've been active in Linux development.)
Still, I think it's a testament to Microsoft that an
Karma: Excellent Birds (mostly as a result of listening to Laurie Anderson)
The only case where I really cared about driver compatibility was once where the I/O card we had in the lab was distributed with DOS drivers (the company since disappeared). Unfortunately, these particular drivers only worked under Win98 and older - all poorly supported versions of Windows. As a result, we ended up having to buy all new cards in order to upgrade. At least if we had the source we could have tried porting the drivers...
.EXE running under multiple versions of Windows. I can download a large number of *nix programs, compile, and run under numerous flavors of Linux, BSD, and other OS's. In fact, most are already precompiled for the favorite distros. Office suites, window managers, scientific apps, LaTeX... its all available.
Whoopee about an
As far as development goes, my limited experience has found Linux to be much nicer. Under Windows, you have to download the whole DirectX SDK (100s of MBs) just to capture frames from a webcam. This also requires the use of VisualC++. Under Linux, simply compile the apropriate USB modules and you're ready to go.
Yeah, call me a troll if you wish, but I really do think it is amazing how so many people here are willing to beg and plead on their knees that the Linux kernel developers freeze the driver API so that closed, proprietary-source hardware companies can write closed-source drivers for their favorite wardware device.
So then, let's take it a step further: would you people also be willing to put up with a totally closed-source kernel, and a closed-source C compiler, if the hardware manufacturers demanded it? In that case, why not just use Windows?
Seriously, I fail to understand why you people want to use Linux, only to complain about the lack of hardware support, since the Linux world requires everything to be open source.
Tell me, would you people also be willing to jump off a bridge to get driver support if the hardware manufacturers demanded it?
I do believe Linux (or GNU Linux, if you prefer), as a platform (not just the kernel), would not be as open as it is today if the developers didn't insist on such openness. If you people don't care how open things are, then why bother with Linux?
They don't have linux support, period.
They only have a x86 binary only driver and some newbie fans going crazy because they can run quake with accelerated 3d on their system.
Jeroen
Secure messaging: http://quickmsg.vreeken.net/
You know that is a shock to all those that run high end OpenGL apps on linux, apps like 3D modelers and highend CAD/CAM apps.
And face it, x86/AMD64 are the main platforms that Linux is used on.
Nobody's asking Nvidia or ATI to release firmware source or core design documents. You don't have to know how it works to write a driver for it, you only need the documentation on how to interface to it.
I've had enough abrasive sigs. Kittens are cute and fuzzy.
Some kernel developers (me included) don't like the idea of making functions in the kernel available for use by closed source drivers. This way the module loader prevents certain modules from using certain functions.
I feel like getting flamed and losing some karma. It's the day after Valentine's anyway, so it's not like I was expecting to be happy anyway.
Why prevent closed source drivers from using certain kernel functions?
Sure, I realize it makes a political point to closed source developers: "your code will remain second-class code until you show us the source", but like a SPEWS blacklist, it does that by annoying innocent third parties in the hopes of getting the third parties to join you in your complaints.
In this case the innocent third parties are the people running linux. So linux users get punished by linux developers for "consorting" with the "enemy's" closed source drivers. Ironically, at the same time, linux is promoted as the OS that allows the user full control over his computer.
If you really believe in the user's right to run his PC as he wishes, let him decide whether or not to buy closed-source hardware.
If you don't, then say so: "I'm giving you the benefit of my code, and I'm not charging for it, but it's not really free, as I expect you to adopt my ideology to use it, and to let me dictate to some degree how you use your PC." That's a valid and defensible stance -- but it's a different stance than is usually professed.
And admit that it's a barrier to wider-spread adoption of linux, and factor it in when asked why more people are not using linux.
Opinions on the Twiddler2 hand-held keyboard?
This may be true, and Nvidia may even have a rather handy work-around for the issue, but things like portable cores are just that: a work-around. As it stands right now, very few companies offically offer much Linux support, and we're not just talking 3D graphics here. NICs, sound cards, SCSI cards, and just about every other piece of hardware out there has large swaths of products that are incompatible with Linux, and binary-driver issues have a lot to do with it.
Hardware companies love Linux, and they want to support Linux, but they also have limits to how far they're willing to go; many are not willing to sink resources in to creating drivers that either are difficult to install, or involve exposing their valuable IP. If companies could just have a way to write a binary Linux driver that will "just work," and work for most people, just like it does with Windows and OS X, then that provides a big carrot to them to provide the driver and get the sales. The lack of a binary option makes things more costly to them and more difficult for them, and that deminishs the value of a sale.
Ultimately, the lack of a binary driver interface scares away users and companies alike, and if Linux wants to do better than a niche, and do better than Windows, then it needs to be friendly to everyone, not just the OSS crowd. Some day, Linus is going to have to make a descision between ultimately limiting Linux to the hobbyist, or letting it truely grow to become a popular, de-facto OS; and it's binary drivers that are going to help make the difference.
Been a while hasn't it?
Booting from punch card, setting switches, changing disks, all on a machine (64KB of core memory) that would barely fit in a two-car garage.
I miss the good 'ol days. Damn kids are spoiled these days.
You are being MICROattacked, from various angles, in a SOFT manner.
That's all very nice, but you are missing the point.
It is most definitely the user's right to run his machine as he pleases, however the user has no right whatsoever to demand that someone else gives up his free time to debug his problems. In the case of a closed-source driver doing unknown things to the kernel, it is the very height of arrogance to demand of a total stranger to reverse engineer your personal hardware setup.
It is not about politics. It is about politeness. One does not ask people to do things that by their very nature are extremely hard if not impossible to accomplish at all, especially if people make it known in advance that they do not have the time nor the means (and hence no inclination) to even try.
Mart"I know I will be modded down for this": where's the option '-1, Asking for it'?
Basically, writing a Linux driver for 2.6 is becoming more like writing a loadable module for Apache.
We need companies to write device drivers, since the complexity of something like an nVidia GeForce GPU is simply too much for a small team of people to reverse engineer.
You have created a false binary opposition here. From reading this one would assume that the only alternatives were a reverse-engineered driver written by hobbyists, or a proprietary binary-only driver from the vendor. They are both bad choices, and the vast majority of kernel drivers are built on neither model. They are written as free software either by the manufacturer, or by outside developers based on specifications provided by the manufacturer. A driver from nvidia is only "necessary" because for 5 years they have refused to release any kind of meaningful specifications to driver developers, and they can't really release the source to their own driver because they don't own most of it.
This is actually a step backwards from the historic pattern of support for graphics cards under Linux. Since the first accelerated X11 server for S3 chipsets from 1992 or so most manufacturers were willing either to release specifications, or actually commision outside developers to write open-source drivers for their hardware. When almost all major video chipset makers (with the exception of nvidia) supported Precision Insight's work developing the DRI infrastructure, there was actually a short time where a large fraction of common video hardware was completely supported, out of the box, including accelerated 3D, by a typical Linux distribution. This was BETTER than the typical support pattern for Windows; no need to mess around with downloading drivers or loading them off of vendor CDs, if the distribution had a properly configured kernel you just installed it and it worked. Unfortunately most of the cards with working DRI drivers are basically obsolete now, aside from some low-end ATI Radeon models. This is how hardware should work in Linux, and for some things like ethernet cards and SCSI adapters it basically does.
The problem is that ATI and nvidia do not understand how to properly support free operating systems, and until they do this "problem" is going to persist. Developers are willing to sign NDAs to gain access to these specifications, and if hardware companies would agree to this there would be no need to port their own precious code at all, much less put up with constant whining to open-source it.
"(Man) tries to live his own life as if he were telling a story. But you have to choose: live or tell." --Sartre
if linux want's to go mainstream and come out of the server room linus will have to compromise.
"If Linux wants" again. Linux doesn't want anything than being useful to those who want to run Linux (see Linus' interviews...). The (grand-)parent poster was right: If you want to run Linux, there is usually no problem to find hardware that is supported without the need for proprietary drivers (the exceptions being GFX cards and hardware niche uses).
Yes, it's a problem if you want to migrate your existing hardware. But that hardware will stay usable only for so long. After that, if you really do want to run Linux, you know to check the hardware compatibility before you buy the replacement.
Keep an eye on which arguments are silently dropped in replies. Not always, but often times it's very telling.
...it took me 15 minutes. I grabbed a Makefile from an example, compiled, noticed that the return type for interrupt handlers had changed, fixed that, done.
Riiight. So by "done", you mean "compiled". Classic.