I've been watching twitter for a while now, amused at the ability for it to keep people appraised of what you are doing at the moment, if they really care. I didn't think it was really worth it.
Until I read this post last night which was linked off of some site that I forgot (probably reddit but I did think it was from the every wonderful Arachaia, which if you are a programmer, you should be paying attention to.)
I just couldn't resist...
So, if you want to see what I am doing, RIGHT NOW (well what I just did, it waits for the command to complete before sending it off to twitter), you can follow along right here.
I'm only enabling it on a few of my terminal windows for now, watching me constantly run mutt and offlineimap would get a bit boring.
I wonder how long it's going to be before I type in my password accidentally to this thing. Or until twitter bans me. Any odds on which is going to happen first?
I pity anyone who subscribes to this twit feed, they are going to start hating me very quickly, like the Portland, Oregon local feed already has...
posted Wed, 14 May 2008 in [/diary]
This is a status report for the Linux Driver Project as of April 2008, describing what has happened in the past year of work. It was originally posted on the developer mailing list.
posted Mon, 07 Apr 2008 in [/linux]
Back in July last year, I wrote a paper for the Linux Symposium about who was doing the actual work in the Linux kernel. Today the Linux Foundation has released a new version of it that contains new data, as well as a lot better writing thanks to Jon Corbet of lwn.net and Amanda McPherson of the Linux Foundation.
The paper was released in both html form, and a PDF version for those who like the pretty graphs to be a bit bigger.
It seems that the trade press has picked this up already, with reviews by the 451 group, internetnews.com, cnet, and infoworld, as well as lwn.net.
Funny note, companies are now emailing me complaining that we aren't counting their contributions properly. Hey, the numbers don't lie, take a look at the tools and logs I used to create all of this if you don't believe them.
To be fair to one company, Google, we were incorrectly counting their representation, keeping Andrew Morton in the "Linux Foundation" bucket instead of the "Google" bucket. That will change the list of top companies placing Google somewhere between 10 and 13, I haven't re-run the numbers yet to get the exact placement.
posted Tue, 01 Apr 2008 in [/diary]
I've been carting the "big wall of kernel developers" poster around the world with me for the past 6 months, getting it signed by as many kernel developers as I could find.
First off was the Ottawa Linux Symposium, where the poster was unleashed apon an unsuspecting crowd of people. They mostly just laughed at it, and I had to update a few names by hand for some late patches that slipped in:
At that conference, which had around 600 attendees, I collected 101 different signatures. That ment that 1 out of every 6 people attending that conference, had gotten a patch into the last kernel version that had just come out (2.6.22 at the time.) That's quite a high concentration all in one spot.
I then displayed it at 2007 OSCON. While a fun conference, it is not very kernel oriented at all, and so, I picked up a few more signatures, mostly from Ubuntu people who happened to be attending due to a recent conference.
After that, it was a jump over the pond to the 2007 Linux kernel summit in Cambridge. I collected a few more signatures there, after having to clear off one whole wall of the conference room, much to the hotel's dismay.
Then, it was a few more plane rides, having it get lost by the airline between London and Hamburg, a train ride to Nuremburg, and then a bus ride to the Czech countryside for a SuSE Labs conference. Once again, the hotel staff looked at me strange, but they eventually found a way to set it up, and a few more signatures were aquired.
In the end, I collected 165 signatures, and the poster traveled with me to five different countries.
But today, I finally said goodbye to it. I sent it off in the mail to linux.conf.au, where it is to be raffled off for charity, after collecting a few more signatures that it is missing.
If you see it, say hello, for after lugging it on more airlines that I want to recall, and having to explain it to more airport security people than should have been necessary, it feels strange to not have to tote it after me anymore.
Maybe I'll go create a new poster for all of the work that happened in 2007 in the kernel, that one should only run about 50 meters long and give me something new to lug around the world again...
posted Sat, 19 Jan 2008 in [/diary]
There was a lot of very good press coverage over my last announcement of the restart of the Linux Driver Project and my involvement in it now full time. It's been a few weeks since that announcement, and we now have over 300 different developers signed up to help create, and maintain Linux drivers!
I've also posted a short status report about the current projects, and what is going on with them. Since then, one more project has started, and there are a handful still in the planning stage.
What we need now is more companies participating in the project, we have the developers, but not enough work to keep them busy.
So how do we change this? I'm thinking that possibly, there really isn't a large number of different devices out there that need Linux support written for them.
As proof of this, I give you the Linux Foundation's Vendor Advisory Board. This group of companies publish a list of priorities that they feel need to be worked on in order to help Linux succeed.
Coming in at number 3 is "Device Driver Support". So, I approached this group and asked them specifically what devices did they see in common use that are not supported by Linux (the obvious 2 video cards being a known exception.) Despite this being such a high priority for this group, they had no examples to provide.
And neither do I. I don't currently know of any common piece of hardware in use today that is not supported on Linux. And since these vendors do not know, and I don't, I'm asking the world to help out.
So, please, let me know what specific type of device you know of that is not properly supported on Linux. If you want, please mark up the wiki page at:
Or just email me with your recommendations. If patterns emerge, I'll approach the companies and ask them if they will work with us.
Hopefully with your help, we can find some work for these 310 developers to do :)
posted Mon, 22 Oct 2007 in [/linux]
Way back in January, I announced a program to write Linux drivers for companies for free. When I did that, I never expected the response to be as large as it was.
It turns out that there were two large groups of people who responded to the announcement, companies wanting drivers, and developers wanting to help out.
I never imagined that so many different people would offer to help out. There is a real need for a place where developers can find a "real" project to work on in the Linux kernel. The Kernel Janitors project is a great place to start out, but what to do from there? It turns out that over 100 different developers offered up their services. Clearly this was a huge untapped group of talented people who wanted to help out.
Also, the number of companies expressing interest in this has exceeded all of my wildest expectations. Already this announcement has caused a number of drivers to end up in the main Linux kernel source tree, with more in the pipeline.
But unfortunately, I was not able to handle all of these different developers and company requests on my own. I had a full-time job, and a full part-time hobby doing Linux kernel development. These requests ended up going unanswered, and I sincerely apologize for that.
Now this has all changed.
My employer, Novell, has modified my position to now allow me to work full time on this project. Namely getting more new Linux kernel drivers written, for free, for any company that so desires. And to help manage all of the developers and project managers who want to help out.
We have kicked off the project again with this announcement on the mailing list set up for the developers wishing to help out.
If you want to join this group of people, or are a company wanting a free Linux driver written for them, please see our new web page at:
and follow the instructions there on how to join in.
I can't thank the people who have helped make this possible at Novell enough. They really care about helping make Linux support as many devices as possible, with fully opensource drivers.
Now let's get busy writing code...
posted Thu, 27 Sep 2007 in [/linux]
Just a few random things I wanted to get out about this year's Linux Symposium.
My big "wall of kernel developers" turned out very well, with lots of different people taking pictures of it. I wanted to get everyone who had a patch to sign the thing, and I counted 105 signatures at the end of the week. So, since the attendance was somewhere around 700 people or so, 1/7 of the attendees had gotten a kernel patch into the Linux kernel within the past 2 months.
That is a pretty concentrated number of kernel developers for any type of conference.
I'll be dragging the poster around to different places through the year (OSCON is next), and eventually take it, or send it to linux.conf.au where it will be raffled off for charity.
If you are somewhere you think a lot of kernel developers are going to be, and want me to send you the poster so you can get their signatures, just let me know.
My talk went really well, despite being misquoted about the fact the size of the Linux kernel is growing both with number of individual developers as well as the overall code size. My paper explaining all of this can be found here, and the slides I used for the talk can be found here for people who want to see the real numbers and information provided.
The scripts used to create this information can be found in the paper, and I'll be updating them later in the week, along with the scripts I used to create the big posters too.
Papers you should read if you have not already:
- Len Brown, ACPI in Linux -- Myths vs. Reality
- Zachary A. Brown, Asynchronous system calls
- Venkatesh Pallipadi and Adam Belay, cpuidle - Do nothing, efficiently...
- Inaky Perez-Gonzalez, My bandwidth is wider than yours: Ultrawideband, Wireless USB and WiNET in Linux
- Arnaldo Carvalho de Melo, The 7 dwarves: debugging information beyond gdb
- Steven Rostedt, Internals of the RT Patch
That last one about RT makes me not so afraid of the whole -rt kernel patchset and it even looks kind of fun to me now...
Heck, go read them all, they are all great papers and you will learn something by just browsing through them.
Overall, the conference was great. I had a blast and James's final keynote was great, talking about evolutionary theory, obsolete computer architectures, and how to embrace the myrad of forks we all generate everyday within the Linux communities. What more could anyone want out of a week?
posted Wed, 11 Jul 2007 in [/diary]
Spoken at the final party at this years Linux Symposium by a kernel developer working for a Linux distribution that will not be named:
So the problems started happening when we added the 7th wireless stack to the kernel...
posted Sun, 01 Jul 2007 in [/diary]
So Pete thinks I just do "big announcements" here, so I'll try to stop that and do more frequent little things.
I just got the printed out version of the 2.6.22 kernel developer chart from the printer before flying out to the Linux Symposium and it's amazingly large in person:
Over 40 feet long, hopefully I can find a wall that long for people to be able to look at the thing...
I also uploaded the PDF files if others want to try their hand at printing this monstrosity out.
posted Mon, 25 Jun 2007 in [/diary]
I've been working on the graphics for my Linux Symposium talk and it turns out that the graph of Linux kernel developers and their relationship is a bit larger and more complex than I originally guessed.
I wanted to create a single big poster that showed the whole Signed-off-by: path for the past year or so, but when I finally got it rendered it turned out to be over 165 feet long by 3 feet tall...
Needless to say, that's a bit impractical, so I'm having to resort to graphing each individual release, but they are still turning out quite large, over 40 feet long for some of these.
I've put up some sample renderings if people want to take a look at them:
Be forwarned that they are very large and might crash your browser.
Also ran into the problem that the local Kinkos (an American copy/printing company) can not handle images this big. The PDF version of the file crashes Acrobat Reader, even the professional version, and Illustrator can not handle single images this large. Somehow I need to figure out how to get these banners printed out in time for my plane ride to Ottawa next week.
After spending all week using Inkscape to create these images all I have to say is "it rocks!". I used to use Illustrator a lot a long time ago (the result of a number of college classes in graphic design) and Inkscape does all that, and handles images this large in size with absolutely no problems.
posted Sat, 23 Jun 2007 in [/diary]
First off, I am a Novell employee, but do not speak for the company at all, the following is my personal opinion, but one that is held by a number of different people at different companies...
I've been hearing from a lot of different companies and users about how the current "enterprise" Linux distros manage their kernels and the current problems they are having with them. With all products that bundle up an every-moving target of an OpenSource projects, there are trade-offs and for the past five years or so the two big Linux distros, SUSE and Red Hat have been trying to walk the line between stability and new features and doing so quite well.
But now that we have been living with these models for a few years, a number of problems have come to light, with the way things currently work. This document describes how the current kernels are managed in these two distros, the problems companies and users are having with them, and three proposed solutions.
Current Model of kernels
An "enterprise" Linux kernel as packaged by Red Hat and SUSE is made up of a kernel.org kernel taken from a specific point in time, and then it is tested, tuned, stabilized and then packaged up and supported for usually a long period of time (5-9 years, depending on the product.) After the product is first released, a series of "service packs" or "maintenance updates" (from now on called "major update") are released, about one every 8-18 months depending on the vendor and the length of time the product has been released.
During the time between these major updates, the distro works to ensure that any bugfix or security update that happens will not break any of the current kernel API or internally visible ABI. It does this so that any third-party kernel modules will not need to change or be "recertified" because of them.
Currently both distros provide a way to have third-party module creators register with them and be notified when an internal ABI change is going to happen in order for them to be able to respin their pre-built modules. They also provide ways for third-party modules to be easily created and build against these kernels so as to ease the build issues that can be caused when attempting to build and package against a distro kernel.
When a major update is released, it usually consists of the original kernel version for the product, with a wide range of new features, drivers, and other fixes backported from the currently released kernel.org kernel to the originally released kernel. This enables new hardware to be supported and new features that are requested by the distro's users and partners to be rolled into the product. This release almost always has ABI and API changes due to the new features and drivers.
At the time of this newly released update, all third party modules must be rebuilt and sometimes reworked due to the new features and backports that were applied to the kernel. Hopefully all third-party module vendors work with the distro to be aware of the proposed changes, but sometimes there is a lag before the new modules are available for the customers to use.
An example of how this works can be seen in the latest Novell SLES10 Service Pack 1 release. Originally the SLES10 kernel was based on the 2.6.16 kernel release with a number of bugfixes added to it. At the time of the Service Pack 1 release, it was still based on the 2.6.16 kernel version, but the SCSI core, libata core, and all SATA drivers were backported from the 2.6.20 kernel.org kernel release to be included in this 2.6.16 based kernel package. This changed a number of ABI issues for any external SCSI or storage driver that they would need to be aware of when producing an updated version of their driver for the Service Pack 1 release.
Problems caused by this model
Here are some of the problems that I have heard with customers and partners who have been working with this kind of release model for a number of years:
- Partners have to get their changes, features, and new drivers into the upstream kernel.org kernel in order for the distros to be willing to accept them. After that happens, they must then backport the feature/driver to the older vendor specific kernel, test it to verify everything works properly, and then ask the vendor to accept the patch for their next service pack, by the deadline imposed by the vendor. This causes a lot of extra work by the partners, having to track at least two vendor kernels, as well as the upstream kernel.org tree.
- If the partner misses the release date for the next service pack, their hardware will not be supported within the whole product until 12-18 months later, when the next service pack is released.
- Partners hate working with externally available drivers, through a driver-disk or some other process. Reasons cited for their dislike of this range from confusion of users for how to get access to these drivers, to security issues, to issues surrounding drivers for boot devices or network devices when doing network installs.
- Due to the changing API between each service pack, third-party vendors need to create a different module build for every major product release (RHEL3, RHEL4, etc) as well as for every maintenance update. Because some customers do not upgrade to the latest maintenance update for various reasons, they are forced to support their driver on all maintenance releases, a very large combination.
- It imposes the old Unix slow release cycle on to Linux, cutting off one of the main reasons people switch to Linux in the first place.
- For machines that must work with new hardware all the time (laptops and some desktops), the 12-18 month cycle before adding new device support makes them pretty much impossible to use at times. (i.e. people want you to support the latest toy they just bought from the store.) This makes things like "enterprise" kernels that are directed toward desktops quite uncomfortable to use after even a single year has passed.
Potential solutions and pros and cons of them
Keep doing the same as before. This model has evolved over the years to the current state based on input from partners, users, developers and the companies.
- Pro: People know the model and are used to it.
- Con: See the above listed reasons why partners and third-party vendors dislike it.
Change the major update to only include kernel bugfixes and security fixes. No new features or drivers will be added to the kernel, helping to ensure that the ABI does not change. If an API has to change due to a more intrusive bugfix, this might still happen at this time, but the change is limited to only a specific area, involving a minor number of symbols and structures, instead of large sweeping change like currently happens.
- Pro: Partners will not have to worry about the release cycle of the distro kernels, and only focus on getting their drivers working with a set kernel version, not multiple versions over the lifetime of the product.
- Con: Many new features will not be able to be added in this manner, as they touch core portions of the kernel and can not be updated with external modules (ACPI and the large PCI quirk table for misbehaving hardware are two such examples.)
On every major update, the kernel is updated to the latest kernel.org release, much like the consumer products are (Fedora, openSUSE, Ubuntu, Mandriva, etc.) This will ensure that any upstream update for drivers and new features will be automatically included.
- Pro: All of the latest kernel drivers and features will be automatically supported and included by the distro, enabling the Partners to focus on upstream kernel.org development and not worry about backporting things to older kernel versions. All bugfixes and security updates that the vendor has not included in their minor updates are also pulled in at this time (and there are a lot of them.)
- Con: Partners whose code is not present in kernel.org releases for whatever reason (do not want it, incompatible licenses, etc.) will have to do a bit more work in tracking the new releases, although this should be only be slightly more than the current amount of development and testing that they currently do.
So, what to do? Currently this discussion is happening in the major distros and their partners. Let me know what you think the model should be for enterprise Linux distros in the future.
Do you like one of the currently proposed models above, or do you have some other model you feel would work better?
Thanks to the many different people who read earlier versions of this document and helped to form the ideas here. This includes the whole Novell/SuSE kernel team who while did not all agree with the ideas here, helped out immensely. Also a number of people at different companies helped out, but probably do not wish to be named here, I want to thank them anyway.
posted Tue, 19 Jun 2007 in [/linux]
Ugh, I've been traveling way too much lately, here's a summary of my trips in the past 2 months:
- Nuremberg for work related meeting
- San Francisco for some meeting I can't remember now.
- Stanford for talk to students
- Prague for training of Linux kernel developers
- Los Angles for FreedomHEC
- Tokyo for LinuxWorld Japan
- San Francisco for driver related meeting.
Remember, I live in Portland, not Germany, as many people seem to be surprised when they meet me for the first time. Don't get fooled by my .de email address...
The last two trips happened this week, with me spending only about 48 hours in Tokyo. It was a lot of fun there, but not much time. However, in that span I did get to do the following:
- Give a talk about Linux kernel development based on a mashup of last year's OLS talk and this upcoming year's talk. People actually asked questions, which I am told is very rare for an audience at this kind of event, so I was happy.
- Signed more copies of my O'Reilly driver book, the Japanese translation, than I have for the English version.
- Went to the Tokyo Linux developer meeting (sorry, can't find link, I know they must have one), along with Tony Luck and gave the same talk again. Tony is the ia64 kernel maintainer and remarked that this is one of the few developer audiences that actually like Itanium. I was really impressed by the meeting, there are a lot of good Linux kernel people in Tokyo, it was nice to see some familiar faces and got to meet a lot of new ones. Hopefully I will see some of them at OLS this year.
- Found some neat USB toys to hack on.
- Drooled over the tiny, 1kg dual core laptops and some ultra-mobile machines that I would love to get Linux running on. The future of ultra-mobile devices is looking very good, I can't wait to get one of them soon.
Then the driver meeting in San Francisco sponsored by O'Reilly. Not as many people showed up as expected (only nvidia, IBM and O'Reilly were there), but I think it was very productive. I'll wrote more about this next week, along with a summary of FreedomHEC.
Oh, and now I'm stuck in the SFO airport due to fog, still trying to get home to PDX and have not slept in almost 48 hours. Travel can be fun at times, but other times it's just a major grind to get through...
Time to go play some Lumines, my new addiction...
posted Fri, 01 Jun 2007 in [/diary]
In talking with a lot of different companies recently, I've come to the realization that we really need to do something about companies that violate the kernel's GPLv2 license. It has been a common criticism that "Well, our company abides by the GPL by releasing the code properly for our kernel modules, but what about all of those other companies that do not?" The companies that are good members of the community are getting a lot of pressure by people internal to them to stop releasing the code. This is justified by pointing to the companies that do not release their code as they are not having any "penalties" by doing this.
Previously the kernel community has ignored almost all violators (with the obvious exception of the gpl-violations.org project). The kernel changes so rapidly that it is quite expensive for a company to try to keep up without releasing their changes and becoming part of the community. This has been done by the constant API changes and other rapid evolution that dictates Linux kernel development. However, if a company throws a bunch of money and developers at the problem, it is pretty trivial to keep up with this development model.
Another big problem is the fact that the kernel is created and copyrighted by thousands of individual developers and companies. Companies are usually not eager to sue other companies as they most likely already have business agreements with them. So that leaves the individual developers, but it's hard for an individual to do anything on their own against companies who violate their code.
So, what can the community do to handle these problems? Here's a few ideas that I've come up with:
- continue as before, ignoring violators. But if we do this, more companies will see this as an implicit acceptance of the closed source modules and start to do it more and more.
- Go after companies with legal action. This is good, but it's pretty "mean" and doesn't do much to try to help convert companies who could learn to become good members of the community. Remember, we need their help, and antagonizing them isn't the best way to accomplish this.
- Ask companies who are friendly toward Linux to apply business pressure against these other companies to get them to change their ways.
- Quietly take legal action against companies who violate the license. This has been the way the FSF has done things in the past, and for some instances this does work. But it does not give any publicity for the other offending companies to provide a disincentive.
- Do big public notices of the offending companies. This will work in some cases, but others, not at all.
The best thing to do is probably a mixture of the above, but I really don't have any solid answers as to how to achieve some of them very well. Taking legal action against another company takes time and resources that individual developers do not usually have. Perhaps a combination of these things is probably the best thing to do.
Anyone have any other ideas?
Or how about incentives for companies who do abide by the license and are good community members. What can we do for them that will help make other companies realize the benefits of doing the same? It's usually easier to convince companies of a tangible benefit, rather than just the risks of incurring legal action.
Anyone have any good ideas about how we can help these companies more?
We need to do something, as I don't think that the current status is workable over the long term.
Thanks to everyone who read and provided feedback to early versions of this document. This includes the whole SuSE kernel development team (not all of whom agree with this document, but they provided their input anyway), and members of other companies that probably do not want to be listed here...
posted Wed, 28 Mar 2007 in [/linux]
Due to all of the responses I've gotten for the Linux driver announcement I have gotten a lot of questions asked to me about this. Here is a list of some of the most common ones, and their answers.
Again, if anyone has questions about this program, or wishes to take advantage of it, please feel free to contact me.
Q: You forgot to mention the most obvious benefit to the company, "They might sell more of their devices!" How can they turn down an offer like that?
A: Good point :)
Q: How are you going to write a GPL driver by signing an NDA? Is it going to require a binary blob or some other way of obfuscating the code?
A: No, not at all. I have written many drivers after signing NDAs with companies. They are usually signed either to keep information about the device private until it is announced at a specific date, or to just keep the actual specification documents from being released to the public directly. All code created by this NDA program is to be released under the GPL for inclusion in the main kernel tree, nothing will be obfuscated at all.
Q: This is a lame publicity stunt, Linux development has always been done this way.
A: Well, the NDA program that we have set up with The Linux Foundation is new. But yes, other than that, this is exactly how Linux kernel development has been done. But it is good to point out exactly how it all works for those who are not familiar with how it works.
Q: You are putting the people who do this kind of development for a living out of a job, stop that!
A: This is just not true at all. In fact a number of people who are consultants doing this kind of development have contacted me thanking me for bringing the issue more publicity. They know that some companies really want to pay people to do development and support in order to achieve contractual issues and have some one on the hook for providing support in ways that the community can not guarantee.
Q: Are companies really going to do this?
A: Yes, already we have received a number of serious queries from companies about producing Linux drivers for their devices. More information will be available later when details are firmed up.
Q: Can you write a driver for my [insert device name here] to get it to work? It isn't made anymore and no one has the specs for it.
A: Sorry, but this project is for devices in which we have the specification and hopefully the manufacturer's support. We don't have the time or effort that is needed to reverse engineer the device on our own, sorry.
Q: Do you need developer help for this project?
A: Yes, just drop me an email and I'll add you to the list of people who have volunteered to help out. We are always glad to accept help.
Q: Are companies actually taking you up on this offer?
A: Yes, the initial response to this was amazing, a measurable number of new Linux drivers will be created thanks to this program.
Q: What about helping to get out-of-the-tree GPL drivers into the main kernel tree?
A: A number of people have offered to help out with this in the past, and all code is welcome to Linux. But we aren't going to be pulling in code to the main kernel tree without the permission of the authors.
Q: What about the BSDs?
A: What about them? They are free to do whatever they wish, I have no input into their development at all, sorry.
posted Fri, 09 Feb 2007 in [/linux]
Yes, that's right, the Linux kernel community is offering all companies free Linux driver development. No longer do you have to suffer through all of the different examples in the Linux Device Driver Kit, or pick through the thousands of example drivers in the Linux kernel source tree trying to determine which one is the closest to what you need to do.
All that is needed is some kind of specification that describes how your device works, or the email address of an engineer that is willing to answer questions every once in a while. A few sample devices might be good to have so that debugging doesn't have to be done by email, but if necessary, that can be done.
In return, you will receive a complete and working Linux driver that is added to the main Linux kernel source tree. The driver will be written by some of the members of the Linux kernel developer community (over 1500 strong and growing). This driver will then be automatically included in all Linux distributions, including the "enterprise" ones. It will be automatically kept up to date and working through all Linux kernel API changes. This driver will work with all of the different CPU types supported by Linux, the largest number of CPU types supported by any operating system ever before in the history of computing.
As for support, the driver will be supported through email by the original developers, when they can help out, and by the "enterprise" Linux distributors as part of their service agreements with their customers.
If your company is worried about NDA issues surrounding your device's specifications, we have arranged a program with OSDL/TLF's Tech Board to provide the legal framework where a company can interact with a member of the kernel community in order to properly assure that all needed NDA requirements are fulfilled.
Now your developers will have more time to work on drivers for all of the other operating systems out there, and you can add "supported on Linux" to your product's marketing material.
This offer is in effect for all different types of devices, from USB toys to PCI video devices to high-speed networking cards. If you manufacture it, we can get Linux drivers working for it.
For any questions about this program, please feel free to respond to this email, or contact me directly at greg@kroah.com. I will also be available at FreedomHEC 2007 held adjacent to WinHEC, if anyone wants to bring devices and work face-to-face.
posted Mon, 29 Jan 2007 in [/linux]
My Linux Stuff
RSS