Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Migrating Device Drivers to the 2.6 Kernel 269

Posted by michael from the modprobe dept.
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."
This discussion has been archived. No new comments can be posted.

Migrating Device Drivers to the 2.6 Kernel More

Migrating Device Drivers to the 2.6 Kernel

Comments Filter:

  • uhh... (Score:5, Insightful)

    by epiphani ( 254981 ) <epiphani&dal,net> on Sunday February 15, 2004 @04:34PM (#8288207)
    how is the extra added line of MODULE_LICENCE("x"); make the simple sided 2.6 kernel module substantially more complicated?

    • Re:uhh... (Score:5, Informative)

      by Narchie Troll ( 581273 ) on Sunday February 15, 2004 @04:38PM (#8288230)
      The build process is substantially different. Actually, it's simpler, provided you have a Linux source tree handy. But you can't develop your kernel modules just anywhere anymore.

      Actually, the license macro isn't even necessary, 2.6 is just bitchier about kernel taints.

      • Re:uhh... (Score:5, Informative)

        by megabeck42 ( 45659 ) on Sunday February 15, 2004 @06:01PM (#8288808)
        I gotta just reinforce the fact that the new kbuild system makes compiling kernels outside of the build tree much easier.

        First of all, there's now a symbolic link from /lib/modules/.../build to the kernel source, further with kbuild, it handles all the dependencies and symbols, etc.

        Basically, compiling a module outside of the tree in the old 2.4.x was difficult and if you were using modversions, almost impossible - you need to have the kernel source and kernel configuration - its necessary anyways. Now, all I need to do is

        make -C /usr/src/linux-2.6.2 SUBDIRS=$PWD modules

        and voila, kbuild handles everything for me.

  • If it means we're one step closer to... (Score:5, Funny)

    by rokzy ( 687636 ) on Sunday February 15, 2004 @04:37PM (#8288227)
    fully-functional ATI drivers (with newbie-proof installer), then I for one welcome our complicated-new-kernel overlords.

  • Linux Device Drivers (Score:5, Informative)

    by rjoseph ( 159458 ) on Sunday February 15, 2004 @04:39PM (#8288240) Homepage
    Supposedly the third edition of Linux Device Drivers [oreilly.com] will be released soon, and will be geared towards 2.6 development (obviously). Anyone who's ever wanted/needed to do linux module programming should definitely take a look at this book, it's basically *the* reference.

  • LWN (Score:5, Informative)

    by SecMF ( 256749 ) on Sunday February 15, 2004 @04:40PM (#8288245)
    LWN has some documentation on this for some time now: http://lwn.net/Articles/driver-porting/ [lwn.net]

  • a lot more complicated ? (Score:5, Informative)

    by pytheron ( 443963 ) on Sunday February 15, 2004 @04:42PM (#8288262) Homepage
    From the article linked:-
    ...the most significant change to working with device drivers for the 2.6 Linux kernel are the changes in the build process described in the next section


    The only difference in the skeleton modules described in the article is a MODULE_LICENSE("GPL"); and a "return 0;".


    Breathtakingly difficult ! In fact, the only 'hard' part seems to be changing how (if at all) your module interacts with other kernel components ! If you wrote a module that utilises these aspects of the kernel, moving to a new API would not be that difficult.

  • LWN has far more depth (Score:5, Informative)

    by Rufus211 ( 221883 ) <rufus-slashdotNO@SPAMhackish.org> on Sunday February 15, 2004 @04:43PM (#8288266) Homepage
    There's a 30 article series [lwn.net] over at LWN about porting drivers to 2.5/6 with both overview articles (like this hello world one) and specifics (like how the block layer changed).

  • Linux 2.6... (Score:5, Interesting)

    by Ianoo ( 711633 ) on Sunday February 15, 2004 @04:50PM (#8288312) Journal
    Linux 2.6 really is the best thing since, erm, sliced bread. I've been helping my Linux friends install it on their machines this week, and the difference is rather noticable, to say the least. Hopefully it'll get in place across all the main distros pretty soon and the upgrade path will be easier for those who are afraid of recompiling for themselves (i.e. the vast majority if we want more Linux-on-the-Desktop use).

    One of my biggest problems with the current driver model is the poor-ish support for loading drivers across minor revisions. I prefer GPL, and agree with a lot of the idealogical reasons behind Free and open source software. Companies, OTOH, do not. 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.

    One of the biggest problems at the moment is not being able to go to nVidia's website, download a precompiled binary module for your arch and load it into the kernel. Equally drivers off of a manufacturer's floppy or CD-ROM need to work this way too. Unfortunately it seemed that with Kernel 2.4, even a 0.0.1 difference in version number could mess things up and require recompilation. Has this been improved in 2.6?

    I think that this is the level of compatibility that needs to be achieved before we see more widespread support by the HW manufacturers. It seems like the guys over a freedesktop.org will have their work on a graphical driver loading system in place quite soon, so this part of the deal is essentially solved.

    • Re:Linux 2.6... (Score:5, Informative)

      by The One KEA ( 707661 ) on Sunday February 15, 2004 @05:03PM (#8288402) Journal
      Sorry, but it's not gonna happen. Linus has repeatedly stated that he will never modify the internal APIs of the kernel to make the maintainership of binary-only modules easier for hardware manufacturers. While this attitude may seem unfair and self-serving, it makes sense, and is not likely to change.

      Right now 3D graphics drivers for ATi and NVIDIA cards are the only sticking point in hardware support IMO. Just about every other major component has Linux support, if you do careful research before buying.

      • Re:Linux 2.6... (Score:5, Interesting)

        by be-fan ( 61476 ) on Sunday February 15, 2004 @05:22PM (#8288527)
        NVIDIA cards, anyway, have excellent Linux support. Thanks to the fact that the NVIDIA drivers use a portable core anyway, they seem to be having no problem keeping up with the kernel.

        • Re:Linux 2.6... (Score:5, Interesting)

          by tunabomber ( 259585 ) on Sunday February 15, 2004 @05:58PM (#8288781) Homepage
          Thanks to the fact that the NVIDIA drivers use a portable core anyway, they seem to be having no problem keeping up with the kernel.

          That's interesting. I'm sure I'm not the first person to come up with this idea, but I wonder how easy it would be to create a compatibility layer between the kernel and the modules that accepts a common binary format for the entire life of a kernel release (or maybe all kernel releases?).

          Then you'd only have to port the layer to the newer kernel revision, and all the old binary drivers would work right away.


          If it could be done, it would be a cool hack in league with that module that allows you to run windows drivers (most notably the NTFS driver) in the Linux kernel. IIRC, the performance of this arrangement sucked, but I wouldn't expect it would be as much of a problem with an abstraction layer for Linux binaries since the difference between a Windows DLL and a kernel module is much bigger than the difference between a 2.4.16 kernel module and a 2.4.24 kernel module.

      • Re:Linux 2.6... (Score:4, Insightful)

        by rsmith-mac ( 639075 ) on Sunday February 15, 2004 @06:57PM (#8289171)
        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.

        • Let the market handle it... (Score:5, Interesting)

          by Kjella ( 173770 ) on Sunday February 15, 2004 @09:27PM (#8290037) Homepage
          Let's say, e.g. Munich or IBM or whatnot finds it's time to make a purchase. Requirements: Linux compatible.

          Once you can attribute a significant number of "Lost sales" to "Lack of Linux compatibility", PHBs will demand that it happens. They couldn't care less about the hobbyist, but if large corporations starts running Linux desktops, as is very likely for basic office tasks, they sure as hell care. And so every peripheral used by corporations, which bleed over pretty damn well into consumer peripherals, then consumers starts demanding the same...

          And then the engineers will go "Gah, this binary API is changing *all* the time. Can't we simply release a GPL driver and be done with it?" And then, after a little talk with legal, and probably the PHB again, hopefully it'll happen. Not to mention they can take the GPL code of any similar driver, and copy-paste (with appropriate copyright headers and all, of course) into their own.

          All Linus has to do is to stay strong on this matter - once Linux is past a reasonably critical mass, I suspect it won't really be much of an issue. The strongholds will be where there is no real alternative, mostly GPUs. But it might also be that Linux is hardly used much by heavy gamers - so they don't see much lost sales at all yet.

          I suspect that it will go the other way. Most drivers will become open, and a few will remain closed. Perhaps in the end, if and when Linux is popular enough, they will simply close the kernel to any binary modules, and whichever has the "weaker" OSS drivers would face lost sales. I sure think it's easier to hit companies where it hurts (in their wallet) than getting Linus to change his ideological viewpoint. We're just not there yet.

          Kjella

    • Re:Linux 2.6... (Score:5, Interesting)

      by jbr439 ( 214107 ) on Sunday February 15, 2004 @05:37PM (#8288623)
      My understanding is that Solaris/SunOS has a driver API/ABI that allows forward compatability of drivers across OS versions. The advantages of this are quite obvious. I also understand Linus and others are dead set against this sort of thing.

      However, at the risk of sounding incredibly naive, would it be possible to create a Linux module that presents a forward compatible API/ABI that other modules could be coded against? An abstraction layer, if you will. Thus, on upgrading the kernel, the only thing that would require a recompile (and possibly a rework) would be this uber-module. NVidia drivers, etc would be coded against this module's API/ABI and thus they themselves wouldn't require rework/recompilation.

      Now there are probably good reasons why this can't be done, but I thought I'd throw it out here and watch it be shot down.
      • In cases where it is relatively easy they do. However, in cases where it's hard, they don't. Think about this:

        In 2.2 kernels, it was legal to call function "foo" from interrupt context. However, in 2.4 kernels, foo calls sleep which means it's illegal to call from interrupt context (I'm making this up, it's my understanding that certain things can't be done from interrupt context). You have a module that calls the function "foo" from the interrupt context.

        Now you are in trouble. How do you code aro

    • Re:Linux 2.6... (Score:4, Insightful)

      by foonf ( 447461 ) on Sunday February 15, 2004 @08:25PM (#8289719) Homepage
      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.

  • This may be impolitic, but... (Score:5, Insightful)

    by InterruptDescriptorT ( 531083 ) on Sunday February 15, 2004 @04:52PM (#8288333) Homepage
    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.

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

    • Re:This may be impolitic, but... (Score:4, Informative)

      by Monkelectric ( 546685 ) <{slashdot} {at} {monkelectric.com}> on Sunday February 15, 2004 @05:06PM (#8288422)
      Ummm WTF are you talking about? The Win32s are FILLED with functions that only work on a specific platforms or are buggy on ceartin platforms making them unreliable. Its only plain vanilla applications that work on any platform -- and you'll find alot of code in there that says if(WINDOWS_VERSION == 98) {} elif (WINDOWS_VERSION == 2000) -- thats not really cross platform compatibility.
      • However.. there are only four versions of Windows device driver coders need to worry about.. 98/98SE, ME, 2000, and XP.

        Unfortunately, a driver for kernel 2.4.18 may not work out of the box on kernel 2.4.19, 2.4.20, 2.4.21, 2.4.22, and so on..

    • Re:This may be impolitic, but... (Score:5, Informative)

      by The One KEA ( 707661 ) on Sunday February 15, 2004 @05:07PM (#8288427) Journal
      Sorry, but what you envision is never going to pass. Linus has repeatedly stated that he will not permit the modification of the Linux kernel source in order to cater to the maintainers of binary-only modules. If they refuse to *PL their code, then they must shoulder the burden of maintainership until such time that they do decide to *PL it.

      It would be nice if the code allowed this, but since it doesn't, all we can do is carefully research the support and drivers that do exist and are available for the latest and greatest hardware, before we buy them.
      • Its not just Binary modules that suffer. Think of the amount of man hours that go into maintaining the current GPLed modules to allow usage in newer versions of kernels, its horrendous amounts. Yes its free labour, but that labour could be going to providing more features, code cleanups, auditing, anything but keeping older code working because the kernel coders want to cripple binary modules.

        Yes, a fixed module API across versions would benifit binary modules, but it would also have massive benefits fo

        • Re:This may be impolitic, but... (Score:5, Insightful)

          by pe1rxq ( 141710 ) on Sunday February 15, 2004 @05:52PM (#8288735) Homepage Journal
          And we would have to suffer our mistakes for eternity to come....
          The reason the API changes is because of improvements, not some secret desire to make live hard on other people....

          Jeroen
          • No, the API changes way too much. You do not ever need to make an API totally incompatable with previous versions to add stuff to it, ever heard of backwards compatability? Indeed, add a second API that can be used, deprecate the old one, and add warnings that it is to be discontinued in the next major release of the kernel, it isnt hard. That way you only have an old and new API hanging around at anyone time, and modules work a lot longer with less work than the current situation.
    • An .exe (with or without that extension) will probably also work between version of Linux just fine, as long as you have the various compat libraries installed.

      Drivers, however, are a whole different story, and I seriously question you assertion that a driver written for windows 98 (or whatever) will "pretty much" work on windows 2000 (or whatever). Having done various upgrades of Windows over the years (both at work and home) I have yet to ever see this working. If I did, I would not trust it - and neit

      • Re:This may be impolitic, but... (Score:5, Interesting)

        by x_man ( 63452 ) on Sunday February 15, 2004 @05:36PM (#8288601)
        Having done driver development for both Windows and Linux, each OS has their plus's and minus's:

        Windows good:
        With some effort, my USB networking driver is binary compatible with Win98 through WinXP. This is really awesome because I don't have to spend a lot of time re-writing and re-compiling drivers. For the customer, it just works.

        Windows bad:
        Writing drivers for Windows is like working on your car with the hood welded shut with only a 12-inch diameter hole cut into the top. Driver writing is EXTREMELY complex on Windows. MS tries to hide everything from you with convoluted callbacks and opaque data structures. My first USB networking driver took me two months just to get a basic skeleton running. On Linux, the same driver took me two weeks to completely finish and I'd never written a driver for Linux before.

        Linux good:
        Driver writing is soooo much easier and intuitive (at least for the 2.2/2.4 kernels). One .c file pretty much does it all

        Linux bad:
        Having to recompile for every kernel just bites. I understand and agree with Linus's reasoning for encouraging open source driver development. Alas, the company I work for doesn't.

        So overall, I'd say the Linux driver model is superior for developers but ease of use is what drives mass-adoption of a product. I guess it just depends on your target audience. Our Linux user base, while vocal, is insignficant compared to Windows and even Mac so guess which driver I spend most of my time working on?

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

      What version of Windows have _you_ been running? I've got quite a few drivers that work just fine under 98 and break in XP/2000. Including a couple for which there are no XP/2000 dri

    • Differing experience (Score:2, Insightful)

      by nuntius ( 92696 )
      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...

      Whoopee about an .EXE running under multiple versions of Windows. I c

    • Re:This may be impolitic, but... (Score:5, Interesting)

      by scotch ( 102596 ) on Sunday February 15, 2004 @05:19PM (#8288503) Homepage
      Still, I think it's a testament to Microsoft that an .EXE can run under Windows 95, 98, 2K and XP and most of the time, it's just going to work.

      If the .exe is statically linked perhaps, otherwise, you're going to have all kinds of library problems when moving the sam app between win 95, win 98, win 2k, and win XP. Keep in mind for earlier OSes in the chain, apps frequently shipped with their own shared libraries causing other apps or even the whole system to break.

      I'm not sure about device drivers for Windows, but I would be suprised if there weren't problems with using win 95/98 device drivers with win XP.

      Not to say that updading linux is painfree, I just think you're overstating the case for microsoft products. C library upgrades aren't a big deal, most distros contain compatibility libraries for older versions. There were some serious issues with libc upgrades, but that was years ago. It's really a non-issue in my development experience. Other libraries cause more headaches than libc.

      Attn Mods: How a post that intends to comment on the strain imposed on developers for linux kernel and libc upgrades and also says this "it's been a long time since I've been active in Linux development" can get modded up to +5 informative is beyond me. Insightful or perhaps inciteful, but not informative.

      • If the .exe is statically linked perhaps, otherwise, you're going to have all kinds of library problems when moving the sam app between win 95, win 98, win 2k, and win XP.

        That's funny, I do it all the time with no such problems. You do have to use GetProcAddr if you want to use features that don't exist in the older versions, but that's far from difficult. Sometimes there'll be some subtil change in behavior in things like common dialogs, but nothing earthshattering.

        Microsoft goes to a LOT of trouble t
    • Windows 9x/Me drivers don't work at all on Windows XP. What the hell are you smoking?

      EXEs are completely different from drivers, and drivers do NOT migrate from 9x to NT kernels.

    • Re:This may be impolitic, but... (Score:2, Informative)

      by Anonymous Coward

      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.

      That's not true at all. Any interested party with the knowhow can download the kernel source, fix up an obsolete driver, and send a patch in.

      What's that? It doesn't work when you want to keep your sourcecode private and out of the hands of the developers? Fine, but don't expect help porting, or crufty workarounds to maintain the outdat


    • Fark off - USB devices didn't exist on Windows 95 and had a major revision between Windows 98 and Windows 98SE.

      This is particularly annoying as the driver installer only checks for Windows 98 and then doesn't check for which edition it is - so you can completely trash the Windows cache of drivers and be unable to uninstall the incorrect version.

  • I've always wondered.... (Score:4, Interesting)

    by Anonymous Coward on Sunday February 15, 2004 @05:05PM (#8288413)
    Would it be possible to have some sort of cross-platform driver language like Java for device divers? That would be really cool because each platform could have its own VM and the same driver would run on Windows, Linux (all kernels), Mac, etc.
    • IMNSHO something like FORTH would perhaps be more suited to this. It's an interesting concept, though probably one that won't be implemented in a world where performance is crucial (for things like video cards) or vendors cut corners and tax the CPU (for things like modems).

    • Re:I've always wondered.... (Score:5, Informative)

      by roboros ( 719352 ) on Sunday February 15, 2004 @05:53PM (#8288739) Journal
      The problem is not the language but the interface to the kernel. The C language, which a lot of drivers are written in, is very portable but you still cannot easily take a driver from Windows XP and port it to Linux, because the driver has to provide and call different functions in Windows vs Linux. What would be required is a standardized API for device drivers but that is (IMHO) not likely to happen soon. There are some however some interesting wrappers for using Windows WLAN drivers under Linux [slashdot.org], maybe it would be possible to extend that to other kinds of drivers.

  • Help! 2.6.2 is huge (Score:5, Interesting)

    by Wills ( 242929 ) on Sunday February 15, 2004 @05:11PM (#8288453)
    Wow, this is a tough one. I'd like to port some 2.4.x drivers to 2.6.2 but I have to use a boot floppy for portable devices without a HD or bootROM and the kernel is so HUGE it literally won't fit onto a boot floppy and LILO doesn't seem to work with high-capacity floppies (fdformat /dev/fd0u1760, but LILO fails at the LILO prompt with "40 40 40 ..."):

    ls -l arch/i386/boot/bzImage

    1472687 arch/i386/boot/bzImage

    I've kept my kernel config to the absolute minimum and made everything as modular as possible. On 2.4.24 the bzImage was only 1056223 bytes, now it's jumped by 400kBytes.

    Has anyone any useful tips for cutting the "bloat"?

    • Re:Help! 2.6.2 is huge (Score:5, Informative)

      by The One KEA ( 707661 ) on Sunday February 15, 2004 @05:14PM (#8288472) Journal
      Start with the CONFIG_EMBEDDED option - it allows you to excise a significant amnount of stuff from the kernel image that would otherwise remain unused. If you want more savings, there is a tinykernel tree somewhere that has patches which allows you to remove even more stuff. IIRC the kernels built from this tree can comfortably run with as little as 4MB of RAM.
      • Thanks for the tips. It's an interesting build situation. I'd like to be able to use a non-standard kernel such as CONFIG_EMBEDDED or tinyLinux to get a smaller bzImage but I can't. I have to use a normal fully functional kernel and find some way of getting the 2.6.2 bzImage onto a boot floppy. There are two coupled machines - one is a normal PC, the other has the same CPU but no HD/bootROM. There are certain operational requirements which mean the same kernel image needs to be running on both machines.

        Th

        • I'd like to be able to use a non-standard kernel such as CONFIG_EMBEDDED or tinyLinux to get a smaller bzImage but I can't.

          CONFIG_EMBEDDED isn't non-standard! It's under "General Setup" in 'make menuconfig' (or whatever your favorite config option is).

          By default it leaves all the standard options on, but you can read the help and see if there are any you don't need (do you really need all three IO schedulers for a device with no hard drive?).

          Also, you can certainly turn on "Optimize for size". You're
          • Yeah I know CONFIG_EMBEDDED is standard in the sense of being in the kconfig menus. What I meant was removing functionality most people leave in would make the kernel non-standard and possibly non-functional. I wasn't sure I could afford to lose any of the functionality listed under CONFIG_EMBEDDED. You're right about "Optimize for size" - it's probably worth a try because bzImage is quite close to 1440kBytes. I'll be pleased if it does.

            I wonder what's going wrong with booting by LILO from a high-capacity 1

  • You people are all hypocrites (Score:5, Insightful)

    by ZuperDee ( 161571 ) <[moc.oohay] [ta] [eedrepuz]> on Sunday February 15, 2004 @05:14PM (#8288474) Homepage Journal
    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?

    • Re:You people are all hypocrites (Score:5, Insightful)

      by Anonymous Coward on Sunday February 15, 2004 @05:58PM (#8288779)
      Unstable driver API hurts everyone, not only hardware manufacturers, and helps nobody.

      If a HW company considers Linux support, they will have to decide in terms of money earned vs money spent. If supporting Linux means supporting every kernel version out there + distribution-specific patches, their costs will be high. High costs - no Linux driver :):)

      I know they could release it as GPL, but that is _their_ decisions. OSS & Free Software is not about forcing others to open-source their work (even if their decision sucks ;) but to give people a choice. And that is what it all boils down to. If there were a stable API, those _evil_ HW manufacturers could simply release their drivers as binary only and _we'd_ have a choice of tainting our kernel or not. The _good_ ones will work with Linux developers regardless of stable API or no stable API

      Right now both ATI and NVIDIA use ugly hacks to get past the lack of stable API. And we still use binary-only code for the drivers, it is just not in the kernel. I understand that Linus is very .. protective ... of his work, teh kernel, and doesnat much care about the user-space, but to those using ATI or NVIDIA drivers and being happy about it: would you rather compile a generic piece of ugly hacks and add a binary-only driver or simply install a binary driver. The latter is a whole lot easier and the end result is _exactly_ the same in terms of stability, security and freedom.

      I'd also like to mention that the lack of stable driver API also hurts OSS developers and users. Not every patch (read driver) gets accepted into the mainstream kernel from where it goes to distros. And not everyone knows how to patch, compile and install. And you know what - they shouldn't need to, if Linux is a serious desktop player. They _should_ have a _choice_ to do all that if they wanted to...

      Enough of ranting, off to bed :)

    • You people are all hypocrites

      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.

      Yup. You're right. We slashdotters are all of one heritage,

    • I find your post hard to understand. There are a variety of reasons to use Linux rather than Windows. It is faster. It is more stable. It is more secure. It is more customizable. If you attach a binary driver to Linux, Linux will still be faster, more stable, more secure, etc.

      Even if a person chooses to install Linux because it is open source, there is nothing hypocritical in thereafter installing binary games or drivers on that operating system. The value to the end-user of open source-ness varies depend

    • Tell me, would you people also be willing to jump off a bridge to get driver support if the hardware manufacturers demanded it?

      Who's this WE you're talking about? Some of us ARE the hardware manufacturers! While we are great Linux supporters, we are damn tired of taking support calls, writing FAQs, and loosing business because of customers can't make use of our drivers. I have conversations like this all the time... who is this benefiting?

      CUSTOMER: I need the kernel?
      US: No, the kernel source. You n

  • Tell me (Score:3, Interesting)

    by ZuperDee ( 161571 ) <[moc.oohay] [ta] [eedrepuz]> on Sunday February 15, 2004 @05:19PM (#8288505) Homepage Journal
    Would you people also be willing to put up with a closed-source Linux kernel, if some CPU manufacturer decided tomorrow that they didn't want to release the specs for their instruction set, and said the only way you could write a kernel would be if you submitted to an NDA? Why is it that things like Wireless Network drivers or video drivers are the ONLY thing subject to this kind of thing?
    • That CPU maker would obviously be using a non-x86/PPC/SPARC/Alpha instruction set, and so no one would care about them anyway. Intel, AMD, IBM, etc. already build their processors against documented standards. The only way to prevent open-source kernels would be to completely redesign the instruction set, which would make the processor useless for everything else, too (no commercial vendor is going to sign an NDA and rewrite their OS to support a minor processor with no users).

    • Re:Tell me (Score:3, Informative)

      by Homology ( 639438 )
      Would you people also be willing to put up with a closed-source Linux kernel, if some CPU manufacturer decided tomorrow that they didn't want to release the specs for their instruction set, and said the only way you could write a kernel would be if you submitted to an NDA?

      You do have CPU microcode updates from Intel, and corresponding Linux code to facilitate uploading the code to the CPU : Microcode [urbanmyth.org].

      This microcode is not easily hackable (at least I hope so), and most certainly is not open source.

      • Re:Tell me (Score:2, Insightful)

        by GigsVT ( 208848 )
        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.

  • Easy Migration (Score:5, Interesting)

    by Voivod ( 27332 ) <cryptic.gmail@com> on Sunday February 15, 2004 @05:42PM (#8288658)
    I just had to port a kernel module I wrote for my employer a year or so ago. Told my boss it'd probably take a week. Instead 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. Thanks to the kernel developers out there for making it so easy!

  • LWN also has an excellent series on driver porting (Score:5, Informative)

    by theonlyholle ( 720311 ) on Sunday February 15, 2004 @05:44PM (#8288666) Homepage
    Linux Weekly News [lwn.net] also has a great series on driver porting at http://lwn.net/Articles/driver-porting/ [lwn.net]. It's in the subscription-free area, so go there and have a look at it.
  • I have a driver for an ethernet card that I had to compile - the source came on a disk with the card. Once it was compiled I loaded it with "insmod" and it worked. To get it to come up automatically at boot time, I just created the "rc.modules" file with an "insmod" line in it and everything is fine. This is running on a 2.2 kernel (yes, 2.2, RedHat 7.0), and I really don't have much need to upgrade.

    Now, how is this going to work for 2.6? First of all, NO F*CKING WAY would I even think of re-compiling th
  • ..[besides that its mildy OT]..
    you will maybe get your system up faster if you cheat [cheesily] and grab the config
    from your currently running kernel to start from, provided you have a relatively late
    model 2.4.x || >.
    its the file in most distros thats sitting in /boot called config-2.4.x or 2.4.x.config
    [not really using more than RH or Deb these days, so im sure there are other places/names].
    if you get a working kernel image for 2.6, go back and trim/add options... at least at that point its academ

  • Binary drivers are inevitable (Score:4, Interesting)

    by calica ( 195939 ) on Sunday February 15, 2004 @06:12PM (#8288892) Journal
    It is just a matter of how well we support it. Currently, nothing. The result, we end up using windows drivers. Examples are ndis and ntfs.sys. This trend will continue.

    An alternative, come up with a standard API for each device type (video, ethernet, scsi, etc) Then create a wrapper between the internal API and the spec. Internal API changes, port the wrapper. If we can do it with windows drivers we should be able to come up with something more efficient and less hackish.

    Original API aged poorly? Design a new one and implement the wrapper as another driver. Both can coexist.

    I see no reason Linus would have a problem with this from a tech perspective. It's just another driver. GPL drivers could avoid the wrapper and would remain prefered.

    Parallel implementation with a BSD would avoid most of the licensing issues.

  • This is DRM! (Score:4, Interesting)

    by QuantumG ( 50515 ) <qg@biodome.org> on Sunday February 15, 2004 @08:19PM (#8289687) Homepage Journal
    The insmod man page [die.net] says:

    Some kernel developers require that symbols exported by their code must only be used by modules with a GPL compatible license. These symbols are exported by EXPORT_SYMBOL_GPL instead of the normal EXPORT_SYMBOL. GPL-only symbols exported by the kernel and by other modules are only visible to modules with a GPL-compatible license, these symbols appear in /proc/ksyms with a prefix of 'GPLONLY_'. insmod ignores the GPLONLY_ prefix on symbols while loading a GPL licensed module so the module just refers to the normal symbol name, without the prefix. GPL only symbols are not made available to modules without a GPL compatible license, this includes modules with no license at all.

    Who the hell wrote that? Why was the patch accepted? What part of "I'm in control of my own computer" was too confusing for this guy to understand? Just to make it absolutely perfectly clear, when I say 'insmod foo.o' I expect foo.o to be loaded into the kernel. The only reason why it shouldn't is if there is a dependancy that would make it not work (but I expect to be able to insmod -f throught that). I do not want my kernel checking the license of foo.o and determining whether or not I am allowed to insert the module.

    Even if you make the claim that you have the right to refuse someone who doesn't GPL their module to link to your module, that has absolutely nothing to do with me. It's a matter between you and the guy who isn't GPLing his module. Me, as a user, are free to link any two pieces of software together that I like. You have absolutely no legal claim to stop me. It's my computer. I thought this all was pretty obvious and it was only the stupid corporations that think they can control our lives who write software to stop me doing what I want to do with my computer, now I'm finding linux kernel developers are doing the same.

    If you want to set a "tainted" flag, if you want to show me a warning, that's just fine, go right ahead, but don't ever stop me from doing what I want with my computer. Now I'm going off to hack my kernel to remove this insanity. Who knows, I might post a patch on the kernel mailing list.

  • For an up-to-date kernel book... (Score:5, Informative)

    by salimma ( 115327 ) * on Sunday February 15, 2004 @09:18PM (#8290004) Homepage Journal
    you can read Robert M. Love's Linux Kernel Development [amazon.com], authored by the person who brought us kernel pre-emption, and is now working at Ximian/SuSE on kernel-desktop integration. Can you say Utopia [ximian.com] ?

  • Will 2.6.x improve life for driver devs? (Score:5, Informative)

    by soldack ( 48581 ) <soldacker@yaho o . c om> on Sunday February 15, 2004 @11:49PM (#8290812) Homepage
    I would love see linux really catch up to Windows here. Having worked on Windows and Linux drivers I can honestly say that for me, Windows device driver development is much easier. I am comparing writing Windows 2000/XP device drivers with Linux 2.4.x device drivers. Most that I have worked on are networking, storage, or low level bus drivers.

    The driver APIs in windows appear to be more stable and documented better. The backwords compatiblity that MS allows in their driver model is great. For example, each time a new feature was added, it was always possible to use the old style for a few revisions. For example, when power managment and plug and play were added in Win2k, MS made sure you could still make a driver without the new calls and things would work. Even their wrapper models for networking (NDIS miniport) and storage (SCSI miniport) easily allow backworks compatibility. NDIS is nicely designed with versioning in the structures so that NDIS can know what version of the API the driver supports and handle it correctly.

    The documentation in the DDK help is has improved greatly since the dark NT4 days. MS worked hard to audit the DDK docs and work with the developer community to improve them. These days their isn't much you will find in a header that doesn't have a nice page in the DDK help.

    At each Windows Hardware Engineering Conference and also at the new Driver Developer Conferences they go way out of their way to make life easy for driver developers. On the source front, they provide source for sample drivers of almost every kind...even for some currently shipping internals.

    The debugger is great. From a GUI or command linux, I can reload drivers over my debugger connection (serial or 1394) on a live system. I can connect to my debugger over TCP and remotely debug it. I can do almost everything I can do in a normal application debugger.

    I can get kernel dumps of various types from full memory to 64 kb minidumps. Full memory dumps allow crashes to be totally debugged...much of the guess work is removed when you can see everything that was on the system at the time of death.

    They also have great test tools built in. Between Driver Verifier and the Hardware Compatiblity Tests, a massive number of issues can be caught before the driver even gets to system testing.

    In the linux world, I have to live with weak kernel debuggers and lack of true memory dumps. In real low level driver for a DMA device, in many cases you don't get the nice happy survivable oops...you get the "I need a damn camera and small console font to capture what stack made it out" oops. Every linux 2.4 device driver book should come with a digital camera for debugging! I heard that 2.6 adds some sort of memory dump...a dump to disk would make post-mortems so much easier. Any one know more about this?

    Add to that the constant changes that instantly make documentation outdated and force driver develepers to rewrite with only the new source as their guide. The kernel rev issue is not just a GPL it and recompile...the APIs change and the meanings of status codes change, etc.
    Each kernel revision my company supports requires significant work on our end. Even if it was as simple as a recompile and test, the rate of kernels released makes it difficult for developers and system test groups to keep up. It takes a lot to test high end drivers. Weeks can go into a system test plan for a specific revision of the driver with a specific revision of the kernel only to see a newer kernel suddenly become the "new new" thing.

    On the test tools front, the world is fragmented with some companies having some certification testing but no true driver certification tests. I would love to see a 2.6 storage driver tester and a 2.6 networking driver tester. Is there anything happening on this front?

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close