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

Somenumbers and thoughts on the stable kernels

ByJonathan Corbet, August 27, 2010

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

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

Lờingườ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àngngà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ốngnhư 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ưngkhá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ácnhà phân phối của họ, và những nhân đó, tới lượtchúng, là không dựa trên các loạt nhân ổn định. Thựctế của việc đưa ra các nhân ổn định đã đi được5 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ửalỗi quan trọng đưa tới cho những người sử dụng cácphiê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áclỗi đã được sửa; Linus, khi đó, đã nghĩ rằng bấtkỳ dự kiện nào như vậy cũng sẽ thất bại:

Tôi đã nói cho bạnvấ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ầmthườ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ếubạn đi sai, thì mọi người sẽ kêu rất to, vì cho tớigiờ bạn đã “hứa” với họ một nhân mà là tốthươn so với dòng chính thống. Nói cách khác, thắng lợigầ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ạnhnhư 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-Hartmanvà Chris Wright đã làm. Họ đã đưa ra 2.6.11.1 vào ngày04/03/2005 với tất cả 3 sửa lỗi. Sau 5 năm, Greg (biệtdanh là “Og”) vẫn còn đó (Chris đôi khi không thậttích cực với các cập nhật ổn định lắm). Trong thờigian đó, lịch sử các phiên bản ổn định trông nhưsau:

Muchattention goes toward mainline kernel releases, but relatively fewusers are actually running those kernels. Instead, they run kernelsprovided by their distributors, and those kernels, in turn, are basedoff the stable kernel series. The practice of releasing stablekernels has been going for well over five years now, so perhaps it'stime to look back at how it has been going.

Backin March 2005, the community was discussing ways of getting importantfixes out to users of mainline releases. There was talk ofmaintaining a separate tree containing nothing but fixes; Linus, atthe time, thoughtthat any such attempt was doomed to failure:

I'lltell you what the problem is: I don't think you'll find anybody to dothe parallel "only trivial patches" tree. They'll go crazyin a couple of weeks. Why? Because it's a _damn_ hard problem. Whe-redo you draw the line? What's an acceptable patch? And if you get itwrong, 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 interestingproblems, and there will absolutely be people who claim that you're adick-head and worse, probably on a weekly basis.

Withsuch strong words of encouragement, somebody clearly had to step upto the job; that somebody turned out to be Greg Kroah-Hartman andChris Wright. They released 2.6.11.1on March 4, 2005 with all of three fixes. More than five yearslater, Greg (a.k.a. "Og")is still at it (Chris has not been active with stable up-dates for awhile). During that time, the stable release history has looked likethis:

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

Trongbảng trên, các nhân được in đậm là các nhân vẫn cònnhậ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ộtvài kết luận có thể có ngay từ bảng ở trên. Đầutiê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ểmnày có thể kết luận rằng các phiên bản nhân củachú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ôngviệ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ònmột yếu tố khác trong công việc ở đây nữa. Địnhnghĩa ban đầu về những gì bắt nguồn một bản vá theocâ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ặctươ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ủa2.6.35.4, dù, chúng ta thấy một loạt rộng lớn hơn “cácsửa lỗi” bao gồm cả hỗ trợ cho máy tính xách tayAcerrv620, 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ínhmở 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áccho vi xử lý mới của Intel. Những cải tiến này là, còntranh cãi, tất cả những gì mà những người sử dụngnhân ổn định có thể muốn có. Nhưng họ hoàn toàn nằmngoài cây ổn định này.

Inthe table above, the kernels appearing in bold are those whic-hare still receiving stable up-dates as of this writing (though 2.6.27is clearly reaching the end of the line).

Acouple of conclusions immediately jump out of the table above. Thefirst is that the number of fixes going into stable up-dates hasclearly increased over time. F-rom this one might conclude that ourkernel releases have steadily been getting buggier. That is hard tomeasure, but one should bear in mind that there is another importantfactor at work here: the kernel developers are simply directing morefixes toward the stable tree. Far more developers are looking atpatches with stable up-dates in mind, and suggestions that a patchshould be sent in that direction are quite common. So far fewerpatches fall through the cracks than they did in the early days.

Thereis another factor at work here as well. The initial definition ofwhat constituted an appropriate stable tree patch was severelyrestrictive; if a bug did not cause a demonstrable oops orvulnerability, the fix was not considered for the stable tree. By thetime we get to the 2.6.35.4up-date, though, we see a wider variety of "fixes,"including Acer rv620 laptop support, typo fixes, tracepointimprovements to make powertop work better, the optimisticspinning mutex scalability work, a new emu10k1 sound drivermodule parameter, and oprofile support for a new Intel processor.These enhancements are, arguably, all things that stable kernel userswould like to have. But they definitely go beyond the originalc-harter 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ảncậ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ữngthụt lùi trong cây ổn định là một viễn cảnh gây lolắ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ộtyế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: 5cập nhật cho toàn bộ lịch sử bản cập nhật của2.6.34 là thấp nhất từ trước tới nay, đã chỉ khớpvới loạt 2.6.13. Thậm chí sau đó, 2.6.34 còn có thêm mộtcậ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 chocù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ộtchút tinh chỉnh các dữ liệu của git. 2 nhân đã đượcchọ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, đanglà 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óphàng đầu cho cả 2 nhân:

Youreditor has also, recently, seen an occasional complaint aboutregressions finding their way into stable up-dates; given the volumeof patches going into stable up-dates now, a regression every now andthen should not be surprising. Regressions in the stable tree are aworrisome prospect; one can only hope that the problem does not getworse.

Anothernoteworthy fact is that the number of stable up-dates for most kernelsappears to be falling slowly; the five up-dates for the entire 2.6.34up-date history is the lowest ever, matched only by the 2.6.13 series.Even then, 2.6.34 got one more up-date than had been originallyplanned as the result of a security issue. It should seem obviousthat handling this kind of patch flow for as many as four kernelssimultaneously will be a lot of work; Greg, who has a few otherthings on his plate as well, may be running a little short on time.

Whois actually contributing patches to stable kernels? Your editordecided to do a bit of git data mining. Two kernels were chosen:2.6.32, which is being maintained for an extended period as theresult of its use in "enterprise" distributions, and2.6.34, being the most recent kernel which has seen its final stableup-date. Here are the top contributors for both:

Vàicái tên trong danh sách này sẽ là quen thuộc. Linus khôngcò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ủanhâ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ĩnhvực được chào đón của việc làm vho các thiết bị âmthanh 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ếtvà vinh hạnh. Nhưng - một cách thừa nhận mà không phảilàm bất kỳ dạng nghiên cứu nào - tổng biên tập củabạn nghi ngờ rằng hầu hết những người được liệtkê ở 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ểncác phiên bản dòng chính thống vào các nhân mà phần cònlại của thế giới thực sự muốn để chạy.

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

Somenames on this list will be familiar. Linus never shows up on the listof top mainline contributors anymore, but he does generate a fairnumber of stable fixes. Other names are seen less often in the kernelcontext: Daniel Chen, for example, is an Ubuntu communitycontributor; his contributions are mostly in the welcome area ofmaking audio devices actually work. Some of the people are in thelist above because they introduced the bugs that their patches fix -appearing in that role is not necessarily an honor. But - admittedlywithout having done any sort of rigorous study - your editor suspectsthat most of the people listed above are fixing bugs introduced byothers. They are performing an important and underappreciatedservice, turning mainline releases into kernels that the rest of theworld actually wants to run.

Wecan also look at who is supporting this work:

Nhữngcon số này khớp hoàn toàn với những đóng góp vào nhândò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ácvá lỗi đó.

Chúngta đã làm mà không có cây ổn định cho 10 phiên bản đầucủa 2.6.x, dù, tại thời điểm này, khó mà tưởng tượngbằng cách nào. Trong một thế giới các ý tưởng, mộtphiên bản nhân dòng chính thống có thể không xảy ra chotới khi không còn lỗi nào còn lại; Lịch sử của cácchu kỳ phát triển nhân 2.3 và 2.5 (cả những nhân khácnữa) chỉ ra rằng tiếp cận này không làm việc đượctrong 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ếptớ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ácbả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ớimột điểm, nơi mà cộng đồng đó cần rà soát lại cáctiêu chuẩn cho các bản vá sẽ được đưa vào các bảncậ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 chomột người để quản lý. Còn bây giờ, cây ổn địnhrõ 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.

Thesenumbers quite closely match those for mainline kernel contributions,especially at the upper end. Fixing bugs is said to be boring andunglamorous work, but volunteers are still our leading source offixes.

Wedid 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, amainline kernel release would not happen until there were no bugsleft; the history of (among others) the 2.3 and 2.5 kerneldevelopment cycles shows that this approach does not work in the realworld. There comes a point whe-re the community has to cre-ate a stablerelease and go on to the next cycle; the stable tree allows that forkto happen without ending the flow of fixes into the released kernel.

Thetables above suggest that the stable kernel process is working well,with large numbers of fixes being directed into stable up-dates andwith participation f-rom across the community. There may come a point,though, whe-re that community needs to revisit the standards forpatches going into stable up-dates. At some point, it may also becomeclear that the job of maintaining these kernels is too big for oneperson to manage. For now, though, the stable tree is clearly doingwhat it is intended to do; Greg deserves a lot of credit for makingit work so well for so long.

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

letrungnghia.foss@gmail.com