(Grand Canyon at Sunset)
After spending a few days manning the Plumbers booth at OSCON, I thought I’d post the answer to the question that everyone seemed to want to know – What is a Linux Plumbers Conference? We came up with the word “Plumbing” to describe the low level infrastructure of a Linux System. This includes the Kernel, desktop infrastructure like X and graphics libraries, system utilities like udev and hal, as well as essential libraries like glibc and friends. These components interface with each other at times – some better than others. We hope to provide a forum for people from these types of projects to get together and try to solve problems that are system wide or cross multiple project boundaries.
In addition to the topics to be discussed in the microconfs and the general talks (see http://linuxplumbersconf.org/program/schedule/), we will have “unconference” style talks. We have several smaller rooms available for people to get together and work out specifics, talk about something they didn’t get on the schedule, or have a group hug. These rooms can be reserved at the start of the conference.
August 18th the registration fee for Plumbers will increase to $300. If you haven’t already registered, what are you waiting for?
This documents my personal flow for downloading and installing a Linux kernel with my xHCI and USB 3.0 code. Until the code is in the upstream kernel and shipping in Linux distributions, you'll have to follow these directions to get Linux USB 3.0 support.
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.
rcu_read_lock(), presumably because of concerns about contention or overhead. This blog entry is intended to help address any lingering concerns about rcu_read_lock() contention and overhead.To be fair, at first glance, rcu_read_lock()'s source code does look a bit scary and slow:
static inline void rcu_read_lock(void)
{
__rcu_read_lock();
__acquire(RCU);
rcu_lock_acquire(&rcu_lock_map);
}
However, a closer look reveals that both __acquire() and rcu_lock_acquire() compile to nothing in production kernels (CONFIG_PROVE_LOCKING=n). This leaves __rcu_read_lock(), which is compiled differently for different settings of CONFIG_PREEMPT.
Let's start with CONFIG_PREEMPT=n. We have:
static inline void __rcu_read_lock(void)
{
preempt_disable();
}
And, again for CONFIG_PREEMPT=n:
#define preempt_disable() do { } while (0)
The overall result for rcu_read_lock() when CONFIG_PREEMPT=n is therefore as follows:
static inline void rcu_read_lock(void)
{
}
Similar analysis of rcu_read_unlock()</code> reveals that it is also an empty static inline function for CONFIG_PREEMPT=n. It is to be hoped that this is sufficiently lightweight for most practical purposes. If you find a case where it is too heavyweight, I would be very interested in hearing about it!
That leaves CONFIG_PREEMPT=y, which actually has executable code in its definition of __rcu_read_lock() as follows:
void __rcu_read_lock(void)
{
current->rcu_read_lock_nesting++;
barrier();
}
The first statement is a simple non-atomic increment of a simple int that is located in the task's own task_struct. The barrier in the second statement expands as follows:
#define barrier() __asm__ __volatile__("": : :"memory")
This is an empty asm that generates no code, but that does disable code-motion optimizations that might otherwise move memory references across the barrier() statement. So, the executable code for rcu_read_lock() for CONFIG_PREEMPT=y is as follows:
void rcu_read_lock(void)
{
current->rcu_read_lock_nesting++;
}
A similar analysis of rcu_read_unlock() for CONFIG_PREEMPT=y yields the following:
void __rcu_read_unlock(void)
{
struct task_struct *t = current;
if (t->rcu_read_lock_nesting != 1)
--t->rcu_read_lock_nesting;
else {
t->rcu_read_lock_nesting = INT_MIN;
if (unlikely(ACCESS_ONCE(t->rcu_read_unlock_special)))
rcu_read_unlock_special(t);
t->rcu_read_lock_nesting = 0;
}
}
The common case of a single level of rcu_read_lock() nesting executes the else clause of the first if statement, and only executes the then clause of the second if statement when the RCU read-side critical section was either preempted or ran for several milliseconds.
So in the common case, rcu_read_unlock() for CONFIG_PREEMPT=y executes two tests of task-local variables and two assignments to task-local variables.
This should be sufficiently lightweight for most purposes.
Of course, RCU is intended for read-mostly situations, and RCU updates can have significant overhead, incurring significant latency, CPU overhead, and/or cache misses. That said, there are some special cases where RCU updates can be extremely fast, as shown in Figures 12 and 13 of the supplementary materials to User-Level Implementations of Read-Copy Update. (No, the supplementary materials are not behind a paywall: Click on the “Supplemental Material(PDF)” link.)
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:
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.
Last week I found two tools that make my life better and make me look cool in front of my friends (j/k). So I thought I would share them.
Keeping bookmarks sync'd and accessible Back in the day I used to use a shareware tool to dump my IE bookmarks to html, then upload them via FTP, and then download them again and re-sync. But times have changed and del.icio.us is the new way to bookmark.
For those not in the know del.icio.us is a "social bookmarking" website. The first consequence is that your bookmarks are stored on a globally accessible webserver with an easy to remember URL like http://del.icio.us/philips. The second and more fun aspect is that when you make a bookmark (with one of the great del.icio.us bookmarklets) you can see who else has bookmarked the same page and what other sites may be related and of interest. From this feature I have found some great websites, including my new favorite techno radio station Radio ABF France.
But the coolest part is a plugin for Firefox called Foxlicious that allows you to sync your bookmarks from del.icio.us into a folder, organized by tags. It is great I can bookmark at home, and sync at work, then bookmark at work and sync at home, then; well you get the idea. Zebra Tele-scopic As you may already know I carry with me at most times an analog notebook (you know the paper kind). But I have never been able to find an inexpensive pen that is compact enough to keep in my pocket. Until my faithful run to the store last week where I found it! "It" being the Zebra Tele-scopic pen which is small enough to put in a jean pocket but telescopes into a regular sized and balanced ball point pen. Not only that but they are far cheaper than the Fisher Space Pen. At ~$5.49 US for two tiny telescoping pens with two refills these pens are a great deal!
Hello everyone,
Thanks for making this year’s plumbers conference such an enjoyable event. Next year, we’re planning to co-locate Plumbers with the Kernel Summit and LinuxCon in San Diego from 29-31 August. The current plan is that Plumbers and LinuxCon would run as parallel but separate events. To accommodate the parallelism, we’re still planning on keeping the numbers for Plumbers down to 300 and having a separate registration from LinuxCon. We’re also planning to move the refereed presentations track into LinuxCon itself as a hard core technical track which would still be selected by the Plumbers Programme committe (both Plumbers and LinuxCon attendees would be able to go to this). We plan to keep the two microconference tracks for plumbers only, but also add a third unconference type track, where people could plan meetings and split into discussion groups in a style very similar to Ubuntu Developer Summit (only Plumbers registered attendees would be able to go to this).
If you have any feedback about this plan, please sent it to the current programme committee at lpc2011@virtuousgeek.org
Of course, we’re also looking to recruit another organising and programme committee for 2013, so if you want to volunteer, please read this web page and then send your bid to the plumbers conference steering committee (who are also the Linux Foundation Technical Advisory Board) at tech-board@lists.linux-foundation.org
For those who want a lift to either San Francisco or its airports, we’ve added a new section to the Ride Sharing wiki. Please make sure to note which day you need a lift for (Friday or Saturday) and for drivers what time you’ll be leaving.
I’m doing a lot of things this year – and for the hundredth time, I find myself discarding my previous life and blogs and starting anew.
Last October, in a chocolate-induced haze of post Halloween self-satisfaction, I somehow thought it would be a good idea to volunteer to run the Linux Plumbers Conference in 2009. Portland continues to host the event, which makes it possible for me to help out, along with an extraordinarily strong local Linux development and business ecosystem. Last year’s crew did a heck of a job creating the event for the first time. We’re coasting on their toil and troubles, this year, frankly.
Despite the continual incoming dripdripdrip of somber economic news, tightening budgets, market collapses, layoffs, disappearing finances and individual anxieties, we are somehow crafting together what will be a rather interesting and productive conference.
The outstanding news today was we got a lot closer to signing up another big name for our keynote! It won’t get announced anytime soon, unfortunately, but it will be fantastic if we can get them. We have already lined up Keith Packard, X Window genius and all round great guy to give one of the keynote addresses.
We will also have Linus giving an advanced tutorial on git. It pains me to impose on Linus, but I’m personally very grateful that James Bottomley did the heroic arm-twisting for us. After losing the video of Linus’s git tutorial in 2008, we badly wanted a chance to reassemble our dignity and geek cred.
If you’re a Linux developer in Portland, OR (or for that matter, anywhere else), what are you waiting for? Register already!
Linux Plumbers Conference will run from Sept 23-25 in 2009 at the Downtown Portland Marriott.
A useful tool: slock is a tiny c program that locks your screen like xlock. But, with only 147 lines of very straightforward code it would be very difficult to introduce vulnerabilities :)
I'm pleased to announce that the eXtensible Host Controller Interface (xHCI) 1.0 specification is now publicly available on intel.com. This is the specification for the PC hardware that talks to all your USB 3.0, USB 2.0, and USB 1.1 devices. (Yes, there are no more companion controllers, xHCI is the one host controller to rule them all).
Open, public documentation is always important to the open source community. Now that the spec is open, anyone can fully understand my Linux xHCI driver (although it's currently only compliant to the 0.96 xHCI spec; anyone want to help fix that?). This also means the BSD developers can implement their own xHCI driver.
Curious what a TRB or a Set TR Deq Ptr command is? Want to know how device contexts or endpoint rings work? Go read the spec!
If you’re ever in the state of Oregon, take the time to visit the Rice Mineral Museum. I took a trip there today, and it was eye-opening, staggering, and simply wonderful. This is a world-class museum, a Smithsonian-level collection hiding out in the middle of nowhere, also known as the north end of Shute Road in Hillsboro. Their website and photo gallery simply do not do them justice.
Most of the pieces were so staggeringly beautiful that they far outdid commercial art that’s sold for megabucks. Amongst the very cool things, a slice of the collection comes from Pashan, Pune, one of the several places on this planet I call home.
for real.
I couldn’t have been happier with how the Linux Plumbers Conference went last week. I went back and looked at the original proposal that we had Arjan, Greg, and Randy present to the Linux Foundation, and we seem to have hit all our original goals. From conception we wanted this to be a “working” conference – and from the conversations in the hallways that I overheard, to the discussions in the microconfs that went on, I could see that people were indeed getting together, discussing issues and solving problems. Conferences require a lot of time, effort, and money to do right, and it’s gratifying to feel that something useful will come out of this.
I think that now I can go back to blogging about duck poo and vegetables.