It's been about a year since I did a status report of what's going on in the openSUSE:Tumbleweed repo, let me know if you find this actually useful or not so that I can determine if I should keep it up.

• As everyone knows, Tumbleweed is running on top of openSUSE:12.1, the transition to 12.1 was rocky for some people who thought that Tumbleweed was somehow a "full" distro, and not just an add-on on top of a stable openSUSE release. To make things easier for future updates of the base openSUSE release, please point to the "current" repo, not the explicitly numbers repo. For more details how to do this, see the Tumbleweed wiki page.
• kernel 3.3.0 is in Tumbleweed, and seems to be working well so far.
• KDE 4.8 is now in Tumbleweed, be careful if you previously had added the KDE repo manually to your system, you should now remove it as I have no idea how well it will interact with this.
• Because of the KDE 4.8 update, LibreOffice was dropped from Tumbleweed. This is due to build issues with the package, not any runtime issue that I can determine. LibreOffice fails to build on Factory at the moment as well, and a bug is open about this, hopefully it gets resolved soon.
• XFCE has been updated in Tumbleweed to the latest version
• vim finally showed up, after a brief breakage that I caused, sorry about that, all should be good now.
• To preempt any questions about a GNOME update in Tumbleweed, I am looking into it, but it will not happen until it stabilizes in Factory first.

As always, if anyone knows of any packages they wish to see added to Tumbleweed, please let me know.

Please read the wiki page for Tumbleweed if you have any basic questions about what it is or how to use it. Any other questions, please ask them on the opensuse-factory mailing list.

posted Mon, 26 Mar 2012 in [/linux]

Last week I released the 2.6.32.58 kernel and said it would be the last one of this series that I was releasing. Given that this was one of the most successful kernel series out there, by number of users, I figured it was worth a brief history of how this came to be, and what I have learned from it.

Stable kernel releases

The first stable kernel release, under the "new" model of development, happened with the 2.6.11.1 release, way back on March 4, 2005, almost 7 years ago to today day. Since then, the stable series has been very successfully released for every kernel that Linus releases, following the rules outlined in the file Documentation/stable _ kernel _ rules.txt in the kernel tree.

For more details about how the stable kernel series came to be about, and how it all works, see the presentation I gave a few years ago at the Tokyo LinuxCon conference, 2010.

Originally both me and Chris Wright started releasing the stable kernels, but a few years back, Chris retired from this, and it's been just me ever since.

One important part of the stable releases was the idea of "throw it on the floor" when Linus would release a new kernel. This worked really well for the community users of the stable kernel, but how about the "enterprise" Linux distros?

Enterprise Kernels

My day job at the time was at Novell/SUSE, and we were about to release a product based on the 2.6.16 kernel, SLE10. As engineers, we were staring down the long hallway of pain we were going to have to endure in order to maintain this specific kernel version for the next 5-7 years for our customers. A large part of maintaining an enterprise kernel is digging through the upstream kernel.org bugfixes and backporting them to the kernel where needed. As this was essentially the same thing that I was already doing as part of my upstream stable kernel work, and I had all of the scripts and workflow already created, I decided to try to see how well I could maintain the 2.6.16 kernel for a longer period of time than just the 2-3 months I currently was.

So, with the 2.6.16.1 kernel release, done on March 27, 2006, I started the 2.6.16 kernel series that would go on to live longer than any kernel release I had ever managed. In the end, I put up with that kernel for 855 days, longer than I had ever imagined possible.

I don't remember if I publicly announced this anywhere, but as time went on, I just kept the 2.6.16 kernel alive, backporting patches to it, and doing releases. This base on which to do the SLE10 releases proved invaluable to me and to the users of the SLE10 product. They gained a lot more bugfixes than we had ever found previously, and it made managing the kernel easier in that we now had a base that was "known good" to constantly build upon. To me, this experiment paid off very well, and others noticed, with community users of the 2.6.16 kernel relying on it for their systems as well, for they too wanted a longterm kernel for some machines that could be supported by the community.

Over time, I noticed that as the kernel.org releases moved on, the amount of patches that actually applied to the older kernel dropped off more and more, with a steep drop-off somewhere around 2 years.

The work that went into keeping this kernel alive, and the experience gained from keeping it working for such a long time for enterprise customers, made me write up a proposal about The Future of Enterprise Linux Kernels in June of 2007. Also, at the same time, I gave a talk at the Linux Kernel summit (I think it was that year) about this same topic. I pushed hard at that meeting, saying something like "Living at one kernel version for the lifetime of an enterprise Linux release is wrong."

Despite my goal of getting rid of enterprise Linux distro kernels sticking at a single release, my job went on, and work started at Novell to plan for the SLE11 SP1 release.

The Cabal meets in secret

The kernel developer community is a very tight-knit one. Despite working for companies that compete with each other, we work together daily through email, make fun of each other on IRC, and drink beer together in different cities around the world every few months at various conferences.

During a few of these meetings, in mid to late 2009, the kernel developers working for all of the various distros quickly figured out that the timeline for the next major releases of a number of products appeared to be lining up to happen all near the same timeframe. Because of the success of the 2.6.16 kernel, and how it worked to provide a solid base for a distro to work off of for a long time, we all agreed, informally, to push for a specific kernel release within our communities/companies that I would then maintain in the kernel.org community in the same way I had done for the 2.6.16 kernel release.

We all drifted back to our companies, and planted the seeds that maybe something like the 2.6.32 kernel would be a nice one to do our product on. This planting worked so well, I had to refrain from fits of laughter in one meeting where a project manager got up and said, "We decided that the 2.6.32 kernel would be the best for our product, what does engineering think about this?"

This successfully cumulated in the release of SLE11 SP1, Debian "Squeeze", RHEL 6, Oracle Linux 6, and Ubuntu 10.4 LTS, all based on the 2.6.32 kernel.

Hacking the business models of these different and competing groups, to coordinate on this specific kernel, was one of the (previously) unsung successes of how the community really can achieve remarkable things if they decide to do it.

We did it, now to get down to work keeping this kernel alive.

Success is almost the death of us

Because it was a widespread "secret" that the 2.6.32 kernel was going to be the base of all of these different enterprise releases, a lot of development groups all started rushing to complete things in time for this kernel release. In the end, when 2.6.32 was released on December 2, 2009, it was the third largest kernel ever developed, by number of changes, with 10,998 of them resulting in the rate of 5.46 patches per hour being applied to it over its release cycle (2.6.29 and 2.6.30 had beaten it with 11,718 and 11,989 patches respectively.)

Because of this fixed deadline, it seemed that a number of areas of the kernel were a bit more "unstable" than normal, but the release and testing process of the enterprise distros soon shook all of that mess out by the time they were finally released a number of months later. The worries that we had chosen wrong and rushed things, was now gone.

How long does it live?

With the 2.6.32 kernel being the base of these longterm enterprise distros, it was originally guessed that it would be hanging around for many many years to come. But, my old argument about how moving a kernel forward for an enterprise distro finally sunk in for 2 of the 3 major players. Both Oracle Linux and SLES 11, in their latest releases these few months, have moved to the 3.0 kernel as the base of them, despite leaving almost all other parts of the distro alone. They did this to take advantage of the better support for hardware, newer features, newer filesystems, and the hundreds of thousands of different changes that has happened in the kernel.org releases since way back in 2009.

Debian is planning on their next stable release, and it will be on a newer kernel, and Ubuntu of course has long moved off of the 2.6.32-based kernel for their (monthly?) releases.

So, with the big users of the 2.6.32 kernel moving on, I've decided to no longer support the 2.6.32 kernel. That's not to say it's going to be dead now. The ever capable Willy Tarreau (the 2.4 kernel maintainer) is going to be keeping it alive, slowly, with a very reduced release schedule as time sees fit.

What about RHEL?

Yes, I know, what about RHEL? It turned out that Red Hat wasn't interested in taking advantage of the stable kernel releases of the 2.6.32 kernel that I made. They have their reasons, and they are valid, I'm not trying to say they aren't, but it turned out that these releases I did really didn't provide them much value from their normal operation of how they maintain their kernel. They are sticking with the 2.6.32 kernel for their RHEL 6 product for the near future as far as I can tell, and it works quite well for them and their customers, with one of the largest installed base of any distro out there. I think they pick and choose pieces of the 2.6.32-stable releases as needed, but due to them only releasing a large "one giant patch" for their kernel package, it's a bit hard to tell what they are really doing there.

The numbers

So, how did the 2.6.32 kernel stack up?

It lived (in my hands) for 823 days (only the 2.6.16 kernel lived longer at 855 days). It ended up containing 3,349 patches that matched up with patches in Linus's kernel tree, the most of any stable kernel release by far (2.6.16 only had 991 patches, the next closest was 2.6.27 with 1,596 patches, 3.0 already has 1448 patches after 133 days, so it might end up being the largest eventually.)

The 2.6.32 kernel was the basis of all of the enterprise distros of the time, still running, and will still supported by the major enterprise Linux vendors for many years in the future, so it will live on.

The future

The lessons learned in maintaining the 2.6.32 kernel have cumulated in the proposal I made last year for the longterm kernel.

With the proposed longterm kernel releases being chosen once a year, it's obvious that I'm not giving up on the model of maintaining specific kernel versions for longer than a few months. But the Linux user and developer community has spread way beyond the enterprise Linux distributions over the past few years. They are no longer the primary consumer of the kernel, and it's obvious that the embedded market also needs this type of support. Because of that, I'm working with the LTSI project, to provide a base that a wider range of distros and products can base themselves on.

Will we ever see all of the major distros ever end up basing themselves on the same kernel version? The odds are now less than before, given their shifting release cycles (some faster, some slower than before), and the move forward to newer kernel releases instead of trying to patch together a single kernel for many many years, a move I strongly support.

But, you never know. If you see a group of kernel developers sitting in the corner at a conference, laughing and drinking beer, perhaps they are really plotting how to convince their managers that the idea was really theirs on what kernel they should be picking for the next product...

Thanks

I would personally like to thank the Debian kernel developers, specifically Ben Hutchings, Maximilian Attems, Dann Frazier, Bastian Blank, and Moritz Muehlenhoff. They went above and beyond what any "normal" developer would have done, ferreting patches out of the kernel.org releases and the different vendor kernels and bug tracking systems, backporting them to the 2.6.32 kernel, testing, and then forwarding them on to me. Their dedication to their user community is amazing for such a "volunteer" group of developers.

I firmly believe that without their help, the 2.6.32 kernel would not have been the success that it was. The users of Red Hat and SuSE products owe them a great debt.

Buy them a beer the next time you see them, they more than deserve it.

posted Thu, 08 Mar 2012 in [/linux]

With my recent job change, I'm starting to run into a bunch of people asking "What exactly are you going to be doing now?"

I've tried responding by describing the kernel related stuff I've been doing for the past years, and it turns out that a lot of people didn't even realize I was doing that.

So, here's a short list of some of the things that I'm going to be doing at my new job, and most importantly, how you can track what I do yourself, so that I never have to write a status report again...

Stable kernel releases

I've been releasing the Linux kernel stable releases since way back when they first started up, in mid 2005. Early on, the most excellent kernel developer Chris Wright helped out with this task, but for the past few years, I've been doing this on my own.

These releases take the last kernel released by Linus and add any needed bugfixes and other related patches that have gone into Linus's development tree, and package it all up in a format that users can use themselves during the 2-3 month development cycle time while the kernel developers are madly working on creating the next kernel release.

For a description of what entails a change that is acceptable into the stable kernel releases, and how to get a patch accepted, please see the file Documentation/stable _ kernel _ rules.txt in the kernel source tree.

Every year I pick a specific kernel version and declare that as "longterm". That kernel gets support from me for bugfixes and related things for two years before it is gracefully retired to a more leisurely release cycle by the capable extra-extra longterm maintainer. For details on how the longterm kernel works, and how it is picked, see this older post I wrote on the topic.

If you want to be notified of when these kernels are released, you can do one of the following:

• read lwn.net, they post the announcements mere hours after they happen. They also post lots of other wonderful things, if you aren't reading this site already, you are missing out.
• subscribe to the linux-kernel or stable mailing lists. Note, you will get a lot of other traffic, but it's all good, you wanted to know what was going on in Linux kernel development directly from the developers themselves, right?
• subscribe to my twitter feed. You might get other random blatherings there, but I do post the announcements to it.
• watch the Linux G+ feed, the releases are all announced there.
• subscribe to the google calender feeds of the kernel releases. This is maintained by the talented Tsugikazu Shibata (high powered executive by day, Linux kernel developer by night) and can be found here for the stable kernel releases, here for the main Linux kernel releases, and here for the kernel development releases.

Kernel subsystem maintainer

When I'm not releasing stable kernels, I also maintain a number of different kernel subsystems. These entail USB, driver core, staging, tty, and a variety of other bits of the kernel. Being a maintainer means you read patches from submitters, handle questions from both developers and users about things related to the subsystem (usually bug reports). If a patch looks acceptable, you test it if possible, and apply it to the relevant git tree and push it publicly, and notify the author that it was accepted. Every weekday, these git trees get merged together in the linux-next release, and inevitably, problems are reported and it's up to the maintainer to fix them when they affect their portion of the kernel.

If you are curious as to exactly what portions of the kernel I maintain, look at the MAINTAINERS file in the kernel source tree and search for my name. Those entries will show you exactly where the git tree for the subsystem lives, as well as the proper mailing list to contact if you have questions in those areas.

If you want to follow the development done in these various areas, and what patches I apply, you can subscribe to the RSS feed of the individual git trees listed in the MAINTAINERS file, or you can follow along on the various different mailing lists.

Kernel development

When not releasing kernels or reviewing patches from others, I occasionally get time to fix bugs, rework existing code to solve problems or extend it in various ways, or even rarer, write a new driver for some random hardware device. This is one area that I should be doing more of now that I have extra time available.

Right now I'm working on a driver for a USB to serial device that Linux doesn't support, and I have some ideas for how portions of the driver core can be reworked to handle some areas better (most of that has been suggested by Kay years ago, I really should get around to implementing them...) I also have some ideas on cleaning up some cruftier portions of the kernel that haven't seen any love for many years, but that's more of a long-term goal, no specifics yet.

If you want to follow along with this development, just watch the main kernel tree for commits by me. That can be done by either subscribing to the rss feed for the kernel tree, or just using git and doing simple searches.

I keep my kernel development and maintainership scripts and directory structure in a public github repo, if you are curious about how this type of thing works. There's lots of scripts helpfully named "do.sh" which I really should rename to be a bit more descriptive, but make sense to me relative to the directory they are located in.

I also have lots of talks, scripts, and other minor projects in my public github repo, if you are curious as to other things I work on over time.

Linux Driver Project

Despite the creaky web page, the Linux Driver project is continuing on quite well. We have written a number of new drivers now included in the main kernel tree, as well as maintaining the staging portion of the kernel. I'll be working on revamping the web site to make it a bit more obvious as to what is going on here, but again, the best way to follow this work is to watch the mailing list.

LTSI kernel maintainership

As has been announced in various places, the LTSI project (Long Term Support Initiative) has started up with the goal to provide a kernel that the consumer electronic companies can use to help reduce their maintenance burden, and to provide a common area where they can learn how to get involved in upstream kernel development.

I'm helping in setting the kernel tree for that project up, and getting some of the procedures and processes in place for it to succeed in the long run. For now, until it really gets up and going, I'm also going to be maintaining the tree myself, handling the patches and working on the support scripts to make it easier to develop using it. If you want to track this work, watch the kernel tree, or join the public mailing list.

I'm also talking with lots of different companies that create chips used in consumer devices that have traditionally been out of the main kernel tree, and with others that are active upstream developers, to try to get them all working better together. I'm also working with the Yocto project to see how the two projects can work together in sharing their kernel needs.

To follow the development of this kernel, you can subscribe to the mailing list, read the archives, or just watch the git tree.

Distribution work

I'm still going to continue my maintenance of the openSUSE Tumbleweed distro, as I've come to rely on it, and it really takes almost no time at all to keep up and working properly. To follow along with any Tumbleweed questions/concerns, please read the openSUSE-Factory mailing list. The scripts used to maintain the Tumbleweed distro, and the list of packages in it, can be seen, and watched, in the tumbleweed github repo.

I'm also going to continue to remain a Gentoo developer, and will have time to do more package maintenance there, which I have not had the opportunity over the past few years.

Both of these are distros that I use every day on my development systems and my servers, and are great community-based distributions.

Travel

"You traveled last year as much as people think you do." -- my wife

As usual, I'll be attending all of the various Linux Foundation events held all around the world, as well as other different conferences that I'm invited to and can find time to get to. Odds are I'll also be traveling to different companies to work with their kernel developers on how to get them to integrate better with the upstream kernel community, or how the LTSI kernel can help them out.

So once again, my frequent flier miles status will probably not be downgraded this year, much to my very patient family's despair.

Is that all?

So, hopefully that explains a bit of what I'll be doing in the near future for the upcoming years. Needless to say, I'm thrilled to be working for the Linux Foundation and that they are supporting me in all of this. If there's anything that anyone is thinking I should be doing but seem not to be, please let me know. I want to make Linux succeed and thrive, and whatever I can do to help that out, I will.

posted Mon, 20 Feb 2012 in [/linux]

I thought it would be easier to do a round of stable kernel releases in the middle of the larger kernel merge window, to prevent the next round from being so big (given that there are a lot of patches usually applying during the -rc1 merge window cycle).

So, I've now done:

• Linux 2.6.32.54-rc1 release
• Linux 3.0.17-rc1 release
• Linux 3.1.9-rc1 release
• Linux 3.2.1-rc1 release

Please go test and let me know if there are any problems with any of these kernels. If I've missed any patches that you feel should be in them, also please let me know.

Note, this is most likely going to be the LAST 3.1.y kernel release, so please move off to the 3.2 kernel at this point in time. Maintaining so many different kernel branches all at once is not trivial, and I want to minimize it if at all possible.

posted Tue, 10 Jan 2012 in [/linux]

As 3.2 is now out, here's a note as to the current status of the different stable/longterm kernel trees.

First off, please everyone remember to mark any patch that you want to have applied to the stable kernel trees with a simple:

Cc: stable <stable@vger.kernel.org>

marking in the Signed-off-by: area. Once the patch hits Linus's tree, I will automatically be notified of it and it will be applied if possible. If it does not applied, you will be notified of that.

Note that the address is stable@vger.kernel.org, not the older address that used to be used before October of 2011.

At this time, all stable and longterm kernel trees are being maintained in one big git tree, located at:

git.kernel.org:/pub/scm/linux/kernel/git/stable/linux-stable.git

There are different branches for every different major kernel version.

Here's the different active kernel versions that I am maintaining at the moment:

• 3.2.y - this will be maintained until 3.3 comes out
• 3.1.y - there will be only one, maybe two, more releases of this tree
• 3.0.y - this is the new "longterm" kernel release, it will be maintained for 2 years at the minimum by me.
• 2.6.32.y - this is the previous "longterm" kernel release. It is approaching it's end-of-life, and I think I only have another month or so doing releases of this. After I am finished with it, it might be picked up by someone else, but I'm not going to promise anything.

All other longterm kernels are being maintained in various forms (usually quite sporadically, if at all), by other people, and I can not speak for their lifetime at all, that is up to those individuals.

If anyone has any questions about any of this, please let me know.

posted Mon, 09 Jan 2012 in [/linux]

tl;dr;

• -stable kernel releases stay the same
• this proposal is how we pick the -longterm releases
• -longterm kernels will be picked every year, and maintained for 2 years before being dropped.
• the same Documentation/stablekernelrules.txt will apply for -longterm kernels, as before.

History:

2.6.16 became a "longterm" kernel because my day job (at SUSE) picked the 2.6.16 kernel for its "enterprise" release and it made things a lot easier for me to keep working at applying bugfixes and other stable patches to it to make my job simpler (applying a known-good bunch of patches in one stable update was easier than a set of smaller patches that were only tested by a smaller group of people.)

Seeing that this worked well, a cabal of developers got together at a few different Linux conferences and determined that based on their future distro release cycles, we could all aim for standardizing on the 2.6.32 kernel, saving us all time and energy in the long run. We turned around and planted the proper seeds within the different organizations and low-and-behold, project managers figured that this was their idea and sold it to the rest of the groups and made it happen. Right now all of the major "enterprise" and "stable" distro releases are based on the 2.6.32 kernel, making this trial a huge success.

Last year, two different community members (Andi and Paul) asked me if they could maintain the 2.6.34 and 2.6.35 kernels as -longterm kernel releases as their companies needed this type of support. I agreed, and they have done a great job at this.

Andi reports that the 2.6.35 kernel is being used by a number of different distros, but they will be phased out as their support lifetime expires. There are also a number of embedded users of the kernel as well as some individual ones. So that -longterm kernel is having a lot of benefit for a wide range of users.

Today:

Now that 2.6.32 is over a year and a half, and the enterprise distros are off doing their thing with their multi-year upgrade cycles, there's no real need from the distros for a new longterm kernel release. But it turns out that the distros are not the only user of the kernel, other groups and companies have been approaching me over the past year, asking how they could pick the next longterm kernel, or what the process is in determining this.

To keep this all out in the open, let's figure out what to do here. Consumer devices have a 1-2 year lifespan, and want and need the experience of the kernel community maintaining their "base" kernel for them. There is no real "enterprise" embedded distro out there from what I can see. montaVista and WindRiver have some offerings in this area, but they are not that widely used and are usually more "deep embedded". There's also talk that the CELF group and Linaro are wanting to do something on a "longterm" basis, and are fishing around for how to properly handle this with the community to share the workload. Android also is another huge player here, upgrading their kernel every major release, and they could use the support of a longterm kernel as well.

Proposal:

Here's a first cut at a proposal, let me know if you like it, hate it, would work for you and your company, or not at all:

• a new -longterm kernel is picked every year.
• a -longterm kernel is maintained for 2 years and then dropped.
• -stable kernels keep the same schedule that they have been (dropping the last one after a new release happens.) These releases are best for products that require new hardware updates (desktop distros, community distros, fast-moving embedded distros (like Yocto)).
• the normal -stable rules apply to these -longterm kernels as described in Documentation/stablekernelrules.txt

This means that there are 2 -longterm kernels being maintained at the same time, and one -stable kernel. I'm volunteering to do this work, as it's pretty much what I'm doing today anyway, and I have all of the scripts and workflow down.

Public Notifications:

The current kernel.org site doesn't properly show what is and is not being maintained as a -stable and -longterm kernel. I have a proposal for how to fix this involving 'git notes', I just need to sit down and do the work with the kernel.org admins to get this running properly.

Thoughts?

Feel free to comment on the google+ thread about this, or on the lkml thread.

posted Sun, 14 Aug 2011 in [/linux]

Sixth in a long series of complaints... See part 1 and part 2 and part 3 and part 4 and part 5 for previous atrocities.

There's nothing like waking up and receiving in your inbox, a few scant hours after the merge window has opened up again, a plea for why you haven't already reviewed and applied all 117+ patches that the author sent to you a few weeks ago, back when they well knew you could not apply them due to the merge window being closed.

Oh, and to top it all off, as the message was sent in HTML format, it didn't hit the mailing lists, I was the only one who received it. Because of that, I figured it was better if I just ignored it as well, just like the vger.kernel.org filters did.

I think I'll just ignore this whole set of patches until after LinuxCon Vancouver which should give me enough time to cool off.

This message brought to you by your favorite convicted monopolist.

posted Mon, 08 Aug 2011 in [/linux]

I have a python script that I run all the time as part of my process for emailing out "your patch has been accepted" messages when I accept a Linux kernel patch into one of the many different development trees I maintain. This script's goal is to merely determine the character encoding that the email needs to be sent in, either "UTF-8" or "ISO-8859-1" or "ANSI_X3.4-1968". It's really simple which is great, but it is slow when fed a file of any real length.

For example, the Linux kernel Makefile takes almost 2 seconds to run through this file, even if the file is in the filesytem cache.

The script was written for me by someone else who was tired of getting emails from me in the wrong encoding, and I greatly appreciate it, but they seem to have disappeared, and my python-foo is quite limited these days.

So anyone wanting to speed this up for me, or rewrite it in perl so I can maintain it over time myself (while also speeding it up) would be greatly appreciated.

---

I'm a Google Summer of Code mentor for a project to port Linux to a specific system on a chip that happens to be in a number of older game platforms. Here's one of these devices. I'm going to be in Taipei and Tokyo over the next few weeks, and it would be great if I could pick up one of these myself to help in the debugging effort of this project. Does anyone know of anywhere in either of those cities I might be able to get this device?

And yes, I am pretty familiar with Akihabara in Tokyo and the electronic area in Taipei but I can't recall ever seeing anything like this before in the stores in those areas, but I probably just wasn't paying attention.

Any help finding this would also be greatly appreciated.

posted Tue, 24 May 2011 in [/linux]

My previous plea for help worked out very well. The resulting video of the talk can be seen here, with one of the highlights being the phrase, "It is cheaper to work upstream in the kernel" from Dirk Hohndel who works at Intel. There's a summary of the talk on lwn.net over here if you don't want to sit through the whole video.

Since I received so many good questions that I worked into the talk last time, I figured I would try it again. In a few weeks, I'll be interviewing Linus Torvalds on stage at the LinuxCon Japan conference, with the topic naturally being "20 Years of Linux."

But there's no reason we have to stick with that topic, right? Send me your ideas and questions and I'll do my best to pick through them and come up with something entertaining enough to fill up a 45 minute discussion between two boring Linux kernel developers.

posted Thu, 19 May 2011 in [/linux]

In two separate email threads this week, I have been asked about the status of the Android wakelock issue that has been described in the past. It turns out that people don't realize that the Linux kernel now supports this type of locking, and has for a few releases now.

Rafael J. Wysocki has merged a solution for this into the kernel and done the unthinkable, he documented everything! He wrote an here on lwn.net, and there is a pointer in that article to a 18 page paper describing in great detail the history, proposed solutions and eventual resolution of the problem.

Astute readers will realize that now there are no barriers for merging any out-of-tree Android specific kernel drivers. Send them in, we will take them!

posted Wed, 23 Mar 2011 in [/linux]

In a few weeks, I'm leading a panel discussion at the Linux Foundation Collaboration Summit about "Hardware Success Stories in the Linux Ecosystem". I'm lucky to have a great set of participants from a bunch of companies with a wide range of experience with Linux, so it should be a lot of fun.

Participating are representatives from Intel, Qualcomm, and Texas Instruments.

I'm working on coming up with some topics to cover, but, to keep things lively, what do you think would be good questions to ask these companies?

Send them to me if you have any ideas.

posted Tue, 22 Mar 2011 in [/linux]

As noted before, I get a lot of email every day. A few years ago it got to the point that the number of individual queries coming in was making it so that I really didn't have much time to do much else than answer them. So after messing with some perl scripts I came up with an email bot that sits and watches my inbox for messages it can answer by pointing people at the proper place to ask the question in the first place.

Every once in a while my email bot escapes to the wild. A number of years ago it hit the linux-usb mailing list so I tweaked it to hopefully never post a public location. But just the other day, a recipient decided to forward it on to a number of public mailing lists, which kind of showed that the recipient didn't actually read the message in the first place. A sad commentary on so many levels...

posted Thu, 17 Mar 2011 in [/linux]

Fifth in a long series of complaints... See part 1 and part 2 and part 3 and part4 for previous atrocities.

Heck, It's not like I haven't said all of this before, but it sure seems like no one learns from the past, or reads the documentation that we write for how to actually submit a patch for the kernel. Linux has one of the best documented procedures for how to do this, it's not like it's a secret or something...

Anyway, here's a list of patches that people have sent me in this week alone that have caused me major problems:

• patch was never even build tested, and of course, it breaks when you do build it.
• patch does build, but it was never tested because the patch does the opposite of what the submitter wanted to do.
• patch sent with no authorship
• patch sent with no signed-off-by line
• patch sent with no description of what the patch did
• patch sent with a description, yet it was not the description of the patch itself
• patch sent with a description that the patch only did one thing, yet the patch did 4 different things
• patch sent with a description that made no sense at all
• patch sent in a series of 13 patches, all with the same exact subject, and no description of what the patch did
• a one line patch that if applied, would instantly break the build
• patch that asked for reviews, yet gets angry when you ask why something was done a certain way
• patch that asked for reviews, and when asked, can't explain why code was done a certain way, blaming a non-existent person for that portion
• patch that said it fixed a bug, yet added a new feature without fixing the original bug
• patch for cleaning up coding style issues, yet adds different coding issues
• patches asked for review, yet had obviously never been even run through our automatic "test this patch for sanity" tools.

Yeah, it's been a fun week...

And if anyone ever wonders why code reviewers are grumpy, just look at the above list and understand.

posted Thu, 10 Feb 2011 in [/linux]

Finally, after many years of people asking for this, Linux can now properly support all known Samsung laptop devices. This means we can now handle backlight control, wifi button issues,and the weird "performance mode" keys as well as some of the other function keys.

If you have a Samsung laptop, I suggest looking at the driver in this post on the linux-kernel mailing list, and letting me know if you have any problems with it or not. If your laptop is not listed in the DMI table, please feel free to send me a patch to add it so we can properly support it.

Many thanks to Samsung oh so long ago for providing some of the needed information to get this to work, and to Ingmar Steen for putting all of the pieces together properly to handle the devices that were not being handled by the old in-kernel driver.

posted Wed, 09 Feb 2011 in [/linux]

Instead of the old boring "here's what drivers are being merged and deleted" and the like as I've posted in the past, I thought I'd just write about one specific project that has recently gone public that I think is a great indicator of how far the Linux Driver Project has come these days.

From the very beginning, Novell has been extremely supportive of the Linux Driver Project, allowing me to work on it on company time, and has encouraged companies they partner with to participate in it, to get Linux drivers into the main kernel tree. One such company recently has been Ralink.

Two weeks ago I visited Ralink in person for the second time, in Taiwan. The outcome of this meeting, and the previous ones, can be seen this past week on the rt2x00-users mailing list in these four posts, as well as a number of previous posts from Ralink developers.

As you can see in these posts, Ralink is sending patches for the upstream rt2x00 driver for their new chipsets, and not just dumping a huge, stand-alone tarball driver on the community, as they have done in the past. This shows a huge willingness to learn how to deal with the kernel community, and they should be strongly encouraged and praised for this major change in attitude.

I'd like to thank the developers and managers at Ralink for making this very public change, and for commiting the resources to see this through to have full Linux support for their chipsets in the main kernel tree.

By no means is this something that I can claim full, if even partial credit for. There were numerous people at Ralink, Novell, and HP that helped in getting these meetings to happen, and the work done. I'm just happy to be a tiny part of this.

On a personal note, I'd like to thank the Novell Taipei developer team who helped me on my visits, and whom have turned into wonderful kernel developers on their own accord, contributing many upstream patches, as well as becoming the maintainers for a few different drivers in the kernel tree. Without their help, none of this would have been possible.

posted Wed, 09 Feb 2011 in [/linux]