Summary:

-current will be destabilized for an extended period (on the order of months). A tag (not a branch) will be laid down before the initial checkin, and non-developers should either stick closely to that tag until the kernel stabilizes, or expect large doses of pain. This tag will be laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning beforehand.

Last week, approximately 20 BSD developers got together and discussed how to move FreeBSD's SMP support to the next level. Our effort will be largely based on the work that has been done in BSD/OS, which should make things go much more smoothly than they otherwise might, but we still expect -current to be destabilized for an extended period of time.

Matthew Dillon is currently working on the locking primitives, as well as some changes to the way our top-level kernel locking works. His initial code will not remove spl()s. This code will probably be committed as the first step, as soon as June 26, 00:00 PST, and Peter Wemm will lay a tag down just beforehand. We will give at least 24 hours notice before the tag is laid down. Be forewarned: if you are doing anything with -current besides FreeBSD development, you will probably want to stop tracking -current at that point for a while.

Greg Lehey will be working on the initial cutover to interrupt threads (as well as the lazy interrupt thread context switching code later on). spl()s will go away as soon as interrupt threads start working. Once interrupt threads are working, most of the remaining work of threading the kernel will be able to go on in parallel.

Device driver maintainers will be able to convert device drivers over a period of several months. We expect to have a compatibility shim in place initially, but there will be a hard cutoff date sometime before the release of FreeBSD 5.0 where the compatibility shim is removed. Before getting too excited about this part of the conversion to a threaded kernel, please keep in mind that 1) there will be plenty of time to do this conversion, 2) the conversion is pretty trivial for most drivers, and 3) as we get to the stage where the conversion becomes possible, there will be much more detail about how to do the conversion, as well as the working examples of the first drivers to be converted.

The addition of kernel support for scheduler activations is generally a separate project, but there are some interdependencies between the SMP and scheduler activations changes, especially in the scheduler and the proc structure.

There are many other SMP-related changes that will be made to the kernel that are not specifically mentioned in this email, since they are not of significant interest from a grand overview perspective. However, there are many details, and if you want to follow the technical discussions, you will want to be subscribed to at least the -current and -smp mailing lists.

Finally, here are some notes about the organization of this effort. I was cajoled into acting as the manager of this effort. That doesn't mean I'm going to do all (or even a major part) of the work; it merely means I'm the focal point of communications and decisions made with regard to the project. Right now, there are at least a dozen highly capable FreeBSD developers that have taken an interest in working on this project. We, as a group, have made a number of decisions about how to attack this project. If you want to contribute to technical aspects of the project, please jump in. However, consider that the general direction we're taking with the SMP effort is the result of a number of very knowledgeable people hashing this out over a period of two days; don't expect that direction to change in the short-term. So, if you have grievances about the way this project is being run, complain to me, but please let the other developers work on this in relative peace.