Vài con số và suy nghĩ về các nhân ổn định

Some numbers and thoughts on the stable kernels

By Jonathan Corbet, August 27, 2010

Theo: http://lwn.net/Articles/402512/

Bài được đưa lên Internet ngày: 27/08/2010

Lời người dịch: Bạn sẽ biết vì sao mà chúng ta lại có những nhân hệ điều hành GNU/Linux ổn định. Một cộng đồng rộng lớn đang tiến hành các công việc đó hàng ngày, đã 5 năm qua, chuyên để sửa các lỗi cho nhân. Và cả những con người cụ thể, các công ty cụ thể đã đóng góp nữa chứ. Làm gì có hệ điều hành nào giống như thế này trên trái đất cơ chứ. Tương lai các hệ điều hành mà bạn muốn sử dụng chắc chắn chính là ở đây!.

Nhiều sự chú ý hướng vào các phiên bản nhân dòng chính thống, nhưng khác ít người sử dụng thực sự chạy các nhân này. Thay vào đó, họ chạy các nhân được cung cấp bởi các nhà phân phối của họ, và những nhân đó, tới lượt chúng, là không dựa trên các loạt nhân ổn định. Thực tế của việc đưa ra các nhân ổn định đã đi được 5 năm nay, nên có lẽ đã tới lúc nhìn lại cách mà nó đã và đang được tiến hành.

Quay về năm 2005, cộng đồng đã tranh luận các cách thức có được những sửa lỗi quan trọng đưa tới cho những người sử dụng các phiên bản dòng chính thống. Đã có cuộc nói chuyện về việc duy trì một cây riêng rẽ không chứa gì ngoài các lỗi đã được sửa; Linus, khi đó, đã nghĩ rằng bất kỳ dự kiện nào như vậy cũng sẽ thất bại:

Tôi đã nói cho bạn vấn đề là gì: Tôi không nghĩ bạn sẽ thấy bất kỳ ai đó làm song song “chi cây của các bản vá tầm thường”. Họ sẽ phát điên trong một vài tuần. Vì sao ư? Vì đây là một vấn đề cực khó. Bạn sẽ đi tới đâu được? Bản vá nào là chấp nhận được? Và nếu bạn đi sai, thì mọi người sẽ kêu rất to, vì cho tới giờ bạn đã “hứa” với họ một nhân mà là tốt hươn so với dòng chính thống. Nói cách khác, thắng lợi gần như là bằng 0, sẽ không có những vấn đề thú vị, và tuyệt đối sẽ có những người kêu rằng bạn là tệ hơn, có lẽ trên một cơ sở hàng tuần.

Với những từ mạnh như vậy để khuyến khích, một số người rõ ràng đã bắt đầu tiến hành công việc này; và Greg Kroah-Hartman và Chris Wright đã làm. Họ đã đưa ra 2.6.11.1 vào ngày 04/03/2005 với tất cả 3 sửa lỗi. Sau 5 năm, Greg (biệt danh là “Og”) vẫn còn đó (Chris đôi khi không thật tích cực với các cập nhật ổn định lắm). Trong thời gian đó, lịch sử các phiên bản ổn định trông như sau:

Much attention goes toward mainline kernel releases, but relatively few users are actually running those kernels. Instead, they run kernels provided by their distributors, and those kernels, in turn, are based off the stable kernel series. The practice of releasing stable kernels has been going for well over five years now, so perhaps it's time to look back at how it has been going.

Back in March 2005, the community was discussing ways of getting important fixes out to users of mainline releases. There was talk of maintaining a separate tree containing nothing but fixes; Linus, at the time, thought that any such attempt was doomed to failure:

I'll tell you what the problem is: I don't think you'll find anybody to do the parallel "only trivial patches" tree. They'll go crazy in a couple of weeks. Why? Because it's a _damn_ hard problem. Where do you draw the line? What's an acceptable patch? And if you get it wrong, people will complain _very_ loudly, since by now you've "promised" them a kernel that is better than the mainline. In other words: there's almost zero glory, there are no interesting problems, and there will absolutely be people who claim that you're a dick-head and worse, probably on a weekly basis.

With such strong words of encouragement, somebody clearly had to step up to the job; that somebody turned out to be Greg Kroah-Hartman and Chris Wright. They released 2.6.11.1 on March 4, 2005 with all of three fixes. More than five years later, Greg (a.k.a. "Og") is still at it (Chris has not been active with stable updates for a while). During that time, the stable release history has looked like this:

Nhân	Các cập nhật	Các thay đổi
		Tổng	Theo từng phiên bản
2.6.11	12	79	7
2.6.12	6	53	9
2.6.13	5	44	9
2.6.14	7	96	14
2.6.15	7	110	16
2.6.16	62	1053	17
2.6.17	14	191	14
2.6.18	8	240	30
2.6.19	7	189	27
2.6.20	21	447	21
2.6.21	7	162	23
2.6.22	19	379	20
2.6.23	16	302	19
2.6.24	7	246	35
2.6.25	20	492	25
2.6.26	8	321	40
2.6.27	53	1553	29
2.6.28	10	613	61
2.6.29	6	383	64
2.6.30	10	419	42
2.6.31	14	826	59
2.6.32	21	1793	85
2.6.33	7	883	126
2.6.34	5	599	120
2.6.35	4	228	57

Trong bảng trên, các nhân được in đậm là các nhân vẫn còn nhận các cập nhật ổn định khi bài này được viết (dù 2.6.27 rõ ràng đang đi tới cuối chu kỳ sống).

Một vài kết luận có thể có ngay từ bảng ở trên. Đầu tiên là số lượng các sửa lỗi đi vào các cập nhật ổn định rõ ràng đã gia tăng theo thời gian. Từ điểm này có thể kết luận rằng các phiên bản nhân của chúng ta đã trở nên ít lỗi hơn một cách ổn định. Điều đó khó mà đo đếm được, nhưng phải ghi nhớ trong đầu rằng có yếu tố quan trọng khác trong công việc ở đây: các lập trình viên nhân với các cập nhật ổn định trong đầu, và những gợi ý mà một bản vá nên được gửi theo hướng đó là hoàn toàn thông thường. Cho tới nay các bản vá ít hơn đi qua các cao thủ hơn là họ đã làm trong những ngày đầu.

Còn một yếu tố khác trong công việc ở đây nữa. Định nghĩa ban đầu về những gì bắt nguồn một bản vá theo cây ổn định phù hợp đã là hạn chế rất nghiêm ngặt; nếu một lỗi không gây ra một chỗ bị tổn thương hoặc tương tự, thì việc sửa nó được coi là cho cây ổn định. Với thời gian chúng ta đã có cập nhật của 2.6.35.4, dù, chúng ta thấy một loạt rộng lớn hơn “các sửa lỗi” bao gồm cả hỗ trợ cho máy tính xách tay Acerrv620, sửa các lỗi in ấn, theo dõi những cải tiến để làm cho công việc tốt hơn, công việc làm cho tính mở rộng phạm vi tốt hơn, một tham số module cho trình điều khiển âm thanh mới emu10k1, và sự hỗ trợ khác cho vi xử lý mới của Intel. Những cải tiến này là, còn tranh cãi, tất cả những gì mà những người sử dụng nhân ổn định có thể muốn có. Nhưng họ hoàn toàn nằm ngoài cây ổn định này.

In the table above, the kernels appearing in bold are those which are still receiving stable updates as of this writing (though 2.6.27 is clearly reaching the end of the line).

A couple of conclusions immediately jump out of the table above. The first is that the number of fixes going into stable updates has clearly increased over time. From this one might conclude that our kernel releases have steadily been getting buggier. That is hard to measure, but one should bear in mind that there is another important factor at work here: the kernel developers are simply directing more fixes toward the stable tree. Far more developers are looking at patches with stable updates in mind, and suggestions that a patch should be sent in that direction are quite common. So far fewer patches fall through the cracks than they did in the early days.

There is another factor at work here as well. The initial definition of what constituted an appropriate stable tree patch was severely restrictive; if a bug did not cause a demonstrable oops or vulnerability, the fix was not considered for the stable tree. By the time we get to the 2.6.35.4 update, though, we see a wider variety of "fixes," including Acer rv620 laptop support, typo fixes, tracepoint improvements to make powertop work better, the optimistic spinning mutex scalability work, a new emu10k1 sound driver module parameter, and oprofile support for a new Intel processor. These enhancements are, arguably, all things that stable kernel users would like to have. But they definitely go beyond the original charter for this tree.

Gần đây, tổng biên tập của bạn cũng thấy một lời kêu đôi khi về sự thụt lùi trong việc đưa vào các bản cập nhật ổn định; biết rằng số lượng các bản vá đang được đưa vào các cập nhật ổn định bây giờ, một sự thụt lùi đôi khi không nên ngạc nhiên. Những thụt lùi trong cây ổn định là một viễn cảnh gây lo lắng; một viễn cảnh chỉ có thể hy vọng rằng vấn đề không bị tồi tệ hơn.

Một yếu tố đáng chú ý nữa là số lượng các cập nhật ổn định cho hầu hết các nhân dường như là chậm: 5 cập nhật cho toàn bộ lịch sử bản cập nhật của 2.6.34 là thấp nhất từ trước tới nay, đã chỉ khớp với loạt 2.6.13. Thậm chí sau đó, 2.6.34 còn có thêm một cập nhật nữa ban đầu đã được lên kế hoạch như là kết quả của một vấn đề an ninh. Có thể thấy rõ ràng rằng việc quản lý dạng dòng các bản vá này cho cùng một lúc 4 nhân sẽ có rất nhiều công việc; Greg, người có một ít những thứ khác để phải làm, có thể quản lý được ít thứ trong thời gian ngắn.

Ai đang thực sự đóng góp các bản vá cho các nhân ổn định? Tổng biên tập của bạn đã quyết định làm một chút tinh chỉnh các dữ liệu của git. 2 nhân đã được chọn là: 2.6.32, mà nó đang được duy trì cho một giai đoạn mở rộng là kết quả của việc sử dụng nó trong các phát tán của “doanh nghiệp”, và 2.6.34, đang là nhân gần đây nhất mà đã thấy được cập nhật ổn định cuối cùng của nó. Đây là những người đóng góp hàng đầu cho cả 2 nhân:

Your editor has also, recently, seen an occasional complaint about regressions finding their way into stable updates; given the volume of patches going into stable updates now, a regression every now and then should not be surprising. Regressions in the stable tree are a worrisome prospect; one can only hope that the problem does not get worse.

Another noteworthy fact is that the number of stable updates for most kernels appears to be falling slowly; the five updates for the entire 2.6.34 update history is the lowest ever, matched only by the 2.6.13 series. Even then, 2.6.34 got one more update than had been originally planned as the result of a security issue. It should seem obvious that handling this kind of patch flow for as many as four kernels simultaneously will be a lot of work; Greg, who has a few other things on his plate as well, may be running a little short on time.

Who is actually contributing patches to stable kernels? Your editor decided to do a bit of git data mining. Two kernels were chosen: 2.6.32, which is being maintained for an extended period as the result of its use in "enterprise" distributions, and 2.6.34, being the most recent kernel which has seen its final stable update. Here are the top contributors for both:

Những người đóng góp tích cực nhất cho nhân ổn định - Most active stable contributors
2.6.32			2.6.34
Greg Kroah-Hartman	36	2.0%	Alex Deucher	14	2.8%
Daniel T Chen	32	1.8%	Joerg Roedel	14	2.8%
Linus Torvalds	23	1.3%	Tejun Heo	10	2.0%
Trond Myklebust	23	1.3%	Daniel T Chen	9	1.8%
Borislav Petkov	23	1.3%	Neil Brown	8	1.6%
Ben Hutchings	21	1.2%	Rafael J. Wysocki	8	1.6%
David S. Miller	20	1.1%	Linus Torvalds	7	1.4%
Theodore Ts'o	20	1.1%	Greg Kroah-Hartman	7	1.4%
Tejun Heo	20	1.1%	Alan Stern	7	1.4%
Dmitry Monakhov	20	1.1%	Jesse Barnes	7	1.4%
Takashi Iwai	18	1.0%	Trond Myklebust	7	1.4%
Ian Campbell	18	1.0%	Ben Hutchings	7	1.4%
Jean Delvare	17	0.9%	Tilman Schmidt	7	1.4%
Henrique de Moraes Holschuh	17	0.9%	Avi Kivity	7	1.4%
Yan, Zheng	17	0.9%	Sarah Sharp	7	1.4%
Zhao Yakui	17	0.9%	Ian Campbell	6	1.2%
Alan Stern	17	0.9%	Johannes Berg	6	1.2%
Al Viro	16	0.9%	Jean Delvare	6	1.2%
Alex Deucher	15	0.8%	Johan Hovold	6	1.2%
Dan Carpenter	15	0.8%	Will Deacon	5	1.0%

Vài cái tên trong danh sách này sẽ là quen thuộc. Linus không còn nổi lên trong danh sách những người đóng góp hàng đầu dòng chính thống nữa, nhưng ông tạo ra một con số khá lớn các sửa lỗi ổn định. Những cái tên khác được xem là ít thường xuyên hơn trong ngữ cảnh của nhân: Daniel Chen, ví dụ, là một người đóng góp cho cộng đồng Ubuntu; những đóng góp của ông hầu như trong lĩnh vực được chào đón của việc làm vho các thiết bị âm thanh thực sự làm việc. Một số người trong danh sách ở trên vì họ đã đưa ra các lỗi mà sự sửa các bản vá của họ – xuất hiện theo vài trò đó không nhất thiết và vinh hạnh. Nhưng - một cách thừa nhận mà không phải làm bất kỳ dạng nghiên cứu nào - tổng biên tập của bạn nghi ngờ rằng hầu hết những người được liệt kê ở trên đang sửa các lỗi được giới thiệu từ những người khác. Họ đang thực hiện một dịch vụ quan trọng và không thể đánh giá hết được, chuyển các phiên bản dòng chính thống vào các nhân mà phần còn lại của thế giới thực sự muốn để chạy.

Chúng ta cũng có thể nhìn xem ai đang hỗ trợ công việc này:

Some names on this list will be familiar. Linus never shows up on the list of top mainline contributors anymore, but he does generate a fair number of stable fixes. Other names are seen less often in the kernel context: Daniel Chen, for example, is an Ubuntu community contributor; his contributions are mostly in the welcome area of making audio devices actually work. Some of the people are in the list above because they introduced the bugs that their patches fix - appearing in that role is not necessarily an honor. But - admittedly without having done any sort of rigorous study - your editor suspects that most of the people listed above are fixing bugs introduced by others. They are performing an important and underappreciated service, turning mainline releases into kernels that the rest of the world actually wants to run.

We can also look at who is supporting this work:

Những ông chủ đóng góp tích cực nhất cho nhân ổn định - Most active stable contributors by employer
2.6.32			2.6.34
(None)	275	15.3%	(None)	95	18.7%
Red Hat	267	14.9%	Red Hat	61	12.0%
Intel	194	10.8%	(Unknown)	58	11.4%
(Unknown)	175	9.8%	Novell	45	8.9%
Novell	166	9.3%	Intel	43	8.5%
IBM	95	5.3%	AMD	35	6.9%
AMD	60	3.3%	IBM	17	3.3%
Oracle	40	2.2%	(Academia)	16	3.1%
Fujitsu	33	1.8%	MontaVista	9	1.8%
Atheros	30	1.7%	Fujitsu	9	1.8%
Parallels	29	1.6%	ARM	8	1.6%
Citrix	27	1.5%	Citrix	8	1.6%
(Academia)	26	1.5%	NetApp	7	1.4%
Linux Foundation	24	1.3%	Oracle	7	1.4%
NetApp	23	1.3%	(Consultant)	7	1.4%
Google	23	1.3%	Linux Foundation	7	1.4%
(Consultant)	20	1.1%	Google	6	1.2%
NEC	18	1.0%	Nokia	6	1.2%
Canonical	15	0.8%	NTT	5	1.0%
Nokia	14	0.8%	VMWare	5	1.0%

Những con số này khớp hoàn toàn với những đóng góp vào nhân dòng chính thống, đặc biệt ở nửa trên. Việc sửa lỗi được nói là công việc nhàm chán và không vinh quang, nhưng những người tình nguyện vẫn dẫn dắt nguồn các vá lỗi đó.

Chúng ta đã làm mà không có cây ổn định cho 10 phiên bản đầu của 2.6.x, dù, tại thời điểm này, khó mà tưởng tượng bằng cách nào. Trong một thế giới các ý tưởng, một phiên bản nhân dòng chính thống có thể không xảy ra cho tới khi không còn lỗi nào còn lại; Lịch sử của các chu kỳ phát triển nhân 2.3 và 2.5 (cả những nhân khác nữa) chỉ ra rằng tiếp cận này không làm việc được trong thế giới thực. Đi tới một điểm nơi mà cộng đồng phải tạo ra một phiên bản ổn định và đi tiếp tới chu trình tiếp theo; cây ổn định cho phép đám người đó sinh ra mà không có việc kết thúc dòng sửa lỗi được đưa vào trong các nhân được tung ra.

Các bảng ở trên gợi ý rằng quá trình nhân ổn định đang làm việc tốt, với số lượng lớn các sửa lỗi đang được định hướng trong các cập nhật ổn định và với sự tham gia từ khắp cộng đồng. Có lẽ sẽ tới một điểm, nơi mà cộng đồng đó cần rà soát lại các tiêu chuẩn cho các bản vá sẽ được đưa vào các bản cập nhạt. Đôi lúc, điều này cũng có thể trở nên rõ ràng rằng công việc duy trì các nhân này là quá lớn cho một người để quản lý. Còn bây giờ, cây ổn định rõ ràng đang làm những gì được mong đợi phải làm; Greg xứng đáng nhiều lòng tin cho việc làm cho nó hoạt động quá tốt cho tới nay.

These numbers quite closely match those for mainline kernel contributions, especially at the upper end. Fixing bugs is said to be boring and unglamorous work, but volunteers are still our leading source of fixes.

We did without a stable tree for the first ten 2.6.x releases, though, at this point, it's hard to imagine just how. In an ideal world, a mainline kernel release would not happen until there were no bugs left; the history of (among others) the 2.3 and 2.5 kernel development cycles shows that this approach does not work in the real world. There comes a point where the community has to create a stable release and go on to the next cycle; the stable tree allows that fork to happen without ending the flow of fixes into the released kernel.

The tables above suggest that the stable kernel process is working well, with large numbers of fixes being directed into stable updates and with participation from across the community. There may come a point, though, where that community needs to revisit the standards for patches going into stable updates. At some point, it may also become clear that the job of maintaining these kernels is too big for one person to manage. For now, though, the stable tree is clearly doing what it is intended to do; Greg deserves a lot of credit for making it work so well for so long.

Dịch tài liệu: Lê Trung Nghĩa

letrungnghia.foss@gmail.com