Lịch sử Linux kernel: những quyết định còn tồn tại

Tóm tắt lịch sử Linux kernel

Lịch sử Linux kernel bắt đầu từ phiên bản 0.01 vào tháng 9 năm 1991 và kéo dài đến dòng 7.x đang boot trên các server hiện nay. Danh sách các bản phát hành không phải là phần đáng chú ý nhất. Một số ít quyết định đã định hình kernel, và mỗi quyết định vẫn gây ra hệ quả trên máy chủ bạn thuê trong hôm nay.

Ngày tháng và số phiên bản trong bài này lấy từ kernel.org và lịch sử phát hành do trang này công bố. Tình trạng hiện tại tính đến tháng 8 năm 2026: phiên bản 7.0 ra mắt vào ngày 12 tháng 4 năm 2026, phiên bản 7.1 vào ngày 14 tháng 6 năm 2026, và phiên bản 7.2 đang ở giai đoạn release candidate.

Vì sao lựa chọn GPL năm 1992 vẫn quan trọng

Version 0.01 được phát hành vào ngày 17 tháng 9 năm 1991 theo một giấy phép do Torvalds tự viết. Giấy phép này yêu cầu phân phối mã nguồn và thêm một dòng quan trọng hơn: “Bạn không được phân phối phần mềm này để thu phí, kể cả chi phí ‘xử lý’.” Năm 1991, phần mềm được phát hành trên đĩa mềm, còn việc sao chép và gửi đĩa mềm đều tốn tiền. Điều khoản đó khiến việc phát hành một bản phân phối Linux thương mại trở nên bất khả thi.

Ông đã thay đổi điều đó. Việc chuyển sang GNU General Public License (GPL) được công bố trong ghi chú phát hành của bản 0.12 vào tháng 1 năm 1992 và có hiệu lực từ ngày 1 tháng 2 năm 1992. Version 0.95, phát hành vào tháng 3 năm 1992, là bản đầu tiên được phát hành theo GPL. Mọi doanh nghiệp xây dựng trên Linux về sau đều dựa trên thay đổi này.

Kernel chỉ sử dụng GPL version 2 và chưa bao giờ chuyển sang version 3. Torvalds từ chối việc chuyển đổi vào năm 2007, chủ yếu vì quy tắc chống tivoisation trong GPLv3. Quy tắc này yêu cầu thiết bị phát hành mã GPL cũng phải chấp nhận bản mã đã được sửa đổi. Ông coi phần cứng bị khóa là quyết định kinh doanh của nhà sản xuất. Năm 2017, các nhà phát triển kernel công bố Kernel Enforcement Statement. Tài liệu này vẫn áp dụng một phần của GPLv3: bên khắc phục vi phạm sau khi được thông báo sẽ giữ được giấy phép, thay vì mất giấy phép vĩnh viễn ngay khi có vi phạm đầu tiên.

Trên máy chủ, điều này dẫn đến 2 hệ quả. Binary kernel bạn boot có kèm quyền nhận mã nguồn tương ứng. Vì vậy, không ai có thể cung cấp cho bạn một Linux kernel mà bạn không được kiểm tra hoặc build lại. Thông báo bản quyền của kernel cũng nêu rõ giấy phép không áp dụng cho các user program sử dụng dịch vụ của kernel thông qua system call thông thường. Vì vậy, database độc quyền và monitoring agent có thể được phát hành cho Linux mà không vi phạm giấy phép. Giấy phép permissive tạo ra áp lực ngược lại. Bạn nên hiểu sự khác biệt này trước khi chọn platform: xem Linux và FreeBSD dưới dạng platform máy chủ.

Vì sao kernel nguyên khối thắng trong thực tế

Ngày 29 tháng 1 năm 1992, Andrew Tanenbaum đăng một thông điệp có tiêu đề "LINUX is obsolete" lên newsgroup comp.os.minix. Ông đưa ra hai nhận định. Kernel nguyên khối, trong đó driver và filesystem chạy trong cùng một không gian địa chỉ có đặc quyền, là thiết kế của thập niên 1970. Microkernel, trong đó các thành phần này chạy dưới dạng các process thông thường, mới là tương lai. Ông cũng cho rằng Linux bị gắn chặt với Intel 386 nên sẽ không bao giờ chạy trên nền tảng khác.

Nhận định về khả năng portability được trả lời bằng việc port sang các nền tảng khác. Version 1.2 vào tháng 3 năm 1995 bổ sung Alpha, SPARC và MIPS. Version 2.0 vào tháng 6 năm 1996 bổ sung bản port 64-bit cho Alpha.

Nhận định về thiết kế được trả lời bằng một giải pháp dung hòa. Linux không bao giờ trở thành microkernel. Thay vào đó, Linux có loadable kernel module: các object file được chèn vào kernel đang chạy rồi gỡ ra khi cần, nhờ đó driver được phát hành riêng khỏi kernel binary.

lsmod | head
modinfo virtio_net | head -5

lsmod liệt kê những module hiện đang được load. modinfo in ra file mà module được load từ đó và các parameter mà module chấp nhận. Trên một server ảo, phần lớn đường dẫn disk và network được xử lý bằng module. Vì vậy, một kernel image có thể boot trên phần cứng mà nó chưa từng gặp.

Module mang lại sự linh hoạt đó mà không phải trả chi phí như thiết kế microkernel. Việc cô lập driver trong process riêng yêu cầu một context switch và một message cho mỗi lần gọi. Năm 1992, chi phí này rất lớn.

Chi phí mà Linux vẫn phải trả là điều cần tính đến: module chạy với đầy đủ kernel privilege. Vì vậy, một module lỗi có thể làm toàn bộ máy bị down thay vì chỉ làm một process bị lỗi. Vấn đề này đặc biệt rõ với các module out-of-tree. Một driver của vendor không có trong mainline phải được build lại cho từng kernel mới. DKMS thực hiện việc này trong quá trình upgrade. Nếu quá trình build thất bại, thiết bị sẽ đơn giản là không còn sau khi reboot.

Vì sao SMP mất mười lăm năm để hoàn thiện

Linux 2.0, phát hành vào tháng 6 năm 1996, là kernel đầu tiên hỗ trợ symmetric multiprocessing (SMP), tức là chạy một kernel trên nhiều CPU. Bản triển khai đầu tiên dùng một lock duy nhất là big kernel lock (BKL), nên tại một thời điểm chỉ có một processor được chạy trong phần code của kernel. Vì vậy, CPU thứ hai chỉ giúp ích cho workload thực hiện tính toán trong user space và hầu như không giúp được workload gồm các system call, vì những system call đó phải xếp hàng chờ cùng một lock.

Việc loại bỏ lock này mất mười lăm năm. Các vị trí còn dùng BKL được chuyển sang fine-grained locking, phần lớn do Arnd Bergmann thực hiện. BKL bị xóa trong 2.6.39, phát hành ngày 18 tháng 5 năm 2011. Scheduler cũng được cải tiến theo cùng tiến độ chậm đó: scheduler O(1) trong 2.6.0, Completely Fair Scheduler (CFS) từ 2.6.23 vào năm 2007, và EEVDF, thay thế CFS trong 6.6 vào tháng 10 năm 2023.

Đó là lý do gói 4 vCPU hiện nay không có gì đặc biệt. Tuy nhiên, công việc này cũng cho thấy một giới hạn cần biết. Trên shared virtual server, kernel của bạn lập lịch các thread của bạn, còn hypervisor lập lịch kernel của bạn. Chạy top rồi đọc trường %st. Steal time là lượng CPU mà kernel của bạn đã sẵn sàng sử dụng nhưng host lại cấp cho guest khác, nên không có cách tuning nào bên trong kernel của bạn khôi phục được lượng CPU đó.

Vì sao dòng 2.6 thay đổi cách kernel được phát triển

Trước 2.6, số phiên bản được chia thành các cặp. Số thứ hai là số chẵn nghĩa là dòng ổn định (2.4), còn số lẻ nghĩa là dòng phát triển (2.5). 2.4 được phát hành vào 4 January 2001 và 2.6 vào 17 December 2003, nên người dùng phải chờ gần ba năm cho dòng ổn định tiếp theo. Các bản phân phối không thể chờ, nên backport các thay đổi. Hai vendor cùng phát hành kernel "2.4" thực tế có thể khác nhau hàng nghìn patch.

Cách chia này bị loại bỏ sau 2.6. Mainline hiện mở một merge window kéo dài khoảng hai tuần, nhận các thay đổi mới, sau đó phát hành các release candidate cho đến khi không còn thay đổi đáng kể, rồi phát hành phiên bản mới sau mỗi 9 đến 10 tuần. Đây vẫn là cadence được kernel.org ghi nhận. Nửa còn lại của mô hình xuất hiện vào 4 March 2005 với bản phát hành đầu tiên của stable tree, một bản cập nhật chỉ sửa lỗi cho 2.6.11, do Greg Kroah-Hartman và Chris Wright duy trì. Stable tree nhận các bản sửa lỗi và từ chối các feature mới.

Một hệ quả là số phiên bản không còn là một cam kết. 3.0, 4.0, 5.0 và 7.0 không phải là các bản viết lại. Torvalds tăng số đầu tiên khi số thứ hai tăng đủ lớn để khiến ông thấy phiền, vì vậy 7.0 xuất hiện sau 6.19 vào April 2026. Điều quan trọng với server là distribution của bạn theo dõi branch nào và branch đó còn nhận được các bản sửa lỗi hay không.

BitKeeper đã bị phá vỡ và git ra đời vào tháng 4 năm 2005 như thế nào

Từ tháng 2 năm 2002, kernel được phát triển bằng BitKeeper, một hệ thống kiểm soát phiên bản phân tán độc quyền của công ty BitMover do Larry McVoy thành lập, bắt đầu từ dòng 2.5. BitMover cấp license miễn phí cho các nhà phát triển kernel với một số điều kiện: bạn không được phát triển công cụ kiểm soát phiên bản cạnh tranh và không được reverse engineer BitKeeper. Nhiều nhà phát triển không muốn xây dựng một kernel miễn phí bằng công cụ mà họ không được phép đọc mã nguồn.

Mọi chuyện đổ vỡ vào tháng 4 năm 2005, sau khi Andrew Tridgell trình diễn một chương trình giao tiếp với các repository BitKeeper. BitMover cho rằng đó là reverse engineering và thu hồi license miễn phí. Kernel mất hệ thống kiểm soát phiên bản ngay giữa một chu kỳ phát triển.

Công việc phát triển git bắt đầu vào ngày 3 tháng 4 năm 2005. Torvalds công bố git vào ngày 6 tháng 4. Đến ngày 7 tháng 4, git đã tự lưu trữ mã nguồn của chính nó; tức là lịch sử của git đã được lưu trong git. Lần merge nhiều branch đầu tiên được thực hiện vào ngày 18 tháng 4. Vào tháng 6 năm 2005, git quản lý việc release phiên bản 2.6.12. Sau đó không lâu, Torvalds giao việc bảo trì cho Junio Hamano và quay lại phát triển kernel.

Thiết kế của git xuất phát trực tiếp từ vấn đề đó: hàng nghìn người đóng góp và các maintainer pull code của nhau qua một network mà không ai tin cậy. Mỗi object được đặt tên bằng hash của nội dung. Vì vậy, thay đổi một byte trong history cũ sẽ làm thay đổi tên của mọi commit sau đó. Đó là lý do clone là bằng chứng chứ không chỉ là một tuyên bố. Mọi deploy pipeline, mọi repository cấu hình, code host mà hầu hết team push code lên và git server mà bạn có thể tự chạy đều bắt nguồn từ một tranh chấp license liên quan đến kernel.

Mô hình LTS cam kết gì và không cam kết gì

Mainline không phải bản bạn nên chạy. Một bản phát hành mainline sẽ bị thay thế sau 9 đến 10 tuần. Cây stable tiếp tục nhận bản sửa lỗi trong vài tuần sau mỗi bản phát hành. Các nhánh longterm, thường được gọi là LTS, tiếp tục nhận bản sửa lỗi trong nhiều năm. Đây là các nhánh mà các bản phân phối dùng làm nền tảng.

2.6.32, phát hành vào tháng 12 năm 2009, là phiên bản chứng minh mô hình này hoạt động. RHEL 6, Debian 6, SUSE Linux Enterprise 11 SP1 và Ubuntu 10.04 LTS đều phát hành kèm phiên bản này. Nhánh đó được duy trì đến tháng 2 năm 2016, hơn sáu năm sau khi xuất hiện.

Thời hạn cam kết đã thay đổi nhiều lần. Ban đầu là hai năm, sau đó một số nhánh được duy trì sáu năm. Năm 2023, các maintainer của stable giảm thời hạn mặc định xuống còn hai năm, vì backport bản sửa lỗi vào các cây mã nguồn cũ tốn thời gian của maintainer và các nhánh cũ ít được kiểm thử thực tế. Ngày 25 tháng 2 năm 2026, Greg Kroah-Hartman công bố lại các dự báo dài hơn sau khi thảo luận với những công ty phụ thuộc vào các nhánh này. Framework hiện tại có thời hạn từ ba đến sáu năm.

[
  {
    "kernel": "5.10",
    "released": "2020-12-13",
    "eol_projected": "Dec 2026",
    "maintained_for": 6.0
  },
  {
    "kernel": "5.15",
    "released": "2021-10-31",
    "eol_projected": "Dec 2026",
    "maintained_for": 5.1
  },
  {
    "kernel": "6.1",
    "released": "2022-12-11",
    "eol_projected": "Dec 2027",
    "maintained_for": 5.0
  },
  {
    "kernel": "6.6",
    "released": "2023-10-29",
    "eol_projected": "Dec 2027",
    "maintained_for": 4.2
  },
  {
    "kernel": "6.12",
    "released": "2024-11-17",
    "eol_projected": "Dec 2028",
    "maintained_for": 4.1
  },
  {
    "kernel": "6.18",
    "released": "2025-11-30",
    "eol_projected": "Dec 2028",
    "maintained_for": 3.1
  }
]

Tính đến tháng 8 năm 2026, kernel.org liệt kê 6 nhánh longterm. Nhánh cũ nhất, 5.10, sẽ được duy trì bản sửa lỗi trong 6.0 năm khi kết thúc vào Dec 2026. Nhánh mới nhất, 6.18, được dự kiến duy trì đến Dec 2028, tương đương 3.1 năm nhận bản sửa lỗi.

Hãy xem các mốc thời gian này là mức tối thiểu, không phải một cam kết hợp đồng. Dự báo cho 6.6 và 6.12 đều được kéo dài thêm vào tháng 2 năm 2026. Ngược lại, một nhánh không có người dùng có thể bị dừng duy trì sớm hơn. Thông thường, bản phân phối sẽ chọn kernel thay bạn: Debian 13 phát hành với 6.12, còn Ubuntu 26.04 LTS phát hành với 7.0. Khoảng cách này chính là nội dung thực tế của câu hỏi về LTS và bản phát hành interim trên server, và đó là thay đổi thực sự xảy ra bên dưới khi bạn nâng cấp Ubuntu 24.04 lên 26.04.

Từ đây phát sinh một điểm dễ nhầm. uname -r trên Ubuntu 24.04 sẽ in ra giá trị tương tự 6.8.0-51-generic. Đây là phiên bản nền từ upstream cộng với các bản backport riêng của bản phân phối. Vì vậy, con số này cho biết nhánh bắt đầu từ đâu, chứ không cho biết nhánh đang chứa những bản sửa lỗi nào. Các công cụ quét đánh giá kernel chỉ dựa trên chuỗi phiên bản sẽ tạo cảnh báo sai đối với kernel của bản phân phối chính vì lý do này.

Kernel đang tranh luận về điều gì

Hiện có 2 tranh luận, và cả 2 đều xoay quanh việc ai sẽ thực hiện công việc.

Rust được đưa vào làm thành phần hạ tầng trong phiên bản 6.1 vào tháng 12 năm 2022. Trong phiên bản 7.0, nhãn thử nghiệm đã được gỡ bỏ. Vì vậy, các ngôn ngữ cốt lõi của kernel là C, assembly và Rust, đồng thời quá trình build không còn cần nightly compiler. Tranh luận nằm ở việc bảo trì. Một maintainer C thay đổi interface có thể làm hỏng các Rust binding mà họ không đọc. Câu hỏi đang được tranh luận là ai phải chịu trách nhiệm sửa chúng.

Tranh luận thứ 2 liên quan đến đóng góp bằng AI. Sasha Levin đề xuất một policy vào tháng 7 năm 2025, sau khi ngày càng có nhiều patch có sự hỗ trợ của máy được gửi lên các mailing list. Tài liệu này được commit vào ngày 23 tháng 12 năm 2025 và hiện nằm trong tài liệu về quy trình của chính kernel tại docs.kernel.org/process/coding-assistants.html. AI agent không được thêm tag Signed-off-by, vì dòng này xác nhận Developer Certificate of Origin (DCO) và chỉ con người mới có thể xác nhận. Việc sử dụng công cụ hỗ trợ được khai báo bằng tag Assisted-by:, thay đổi từ Co-developed-by: trong quá trình review vì công cụ không phải là author. Code được sinh tự động phải tương thích với GPL-2.0-only. Người gửi patch phải review patch đó và chịu trách nhiệm về nó.

Áp lực dẫn đến policy này là thời gian review. Việc tạo một patch chỉ mất vài giây, nhưng review một patch có thể chiếm cả buổi chiều của maintainer. Một tag không giải quyết được sự chênh lệch đó. Điều tag này bảo toàn là provenance: lịch sử vẫn ghi lại ai đã ký xác nhận cho từng thay đổi. Đây chính là thuộc tính mà DCO được đưa ra để bảo vệ vào năm 2004.

Ý nghĩa của lịch sử này đối với server bạn thuê

• Giấy phép là lý do bạn có thể đọc và tự build kernel mà nhà cung cấp dùng để boot, đồng thời phần mềm độc quyền vẫn chạy được trên đó.
• Thiết kế nguyên khối là lý do một lỗi trong driver có thể reboot toàn bộ máy, và một module ngoài cây mã nguồn phải được build lại sau mỗi lần nâng cấp kernel.
• Mô hình phát hành là lý do số phiên bản cho bạn biết rất ít, trong khi branch và ngày end-of-life của branch cho biết gần như mọi thứ.
• Loại ảo hóa quyết định những gì bạn có thể làm: trên KVM, bạn boot kernel của riêng mình và load module; còn với ảo hóa container dùng chung kernel của host, uname -r hiển thị phiên bản của host, modprobe sẽ fail, và một số sysctl ở chế độ chỉ đọc.

FAQ

Vì sao Linux kernel vẫn dùng GPLv2 thay vì GPLv3?

Năm 2007, Torvalds quyết định không dùng GPLv3, chủ yếu vì yêu cầu chống tivoisation. Yêu cầu này buộc thiết bị phân phối GPL code cũng phải chấp nhận phiên bản đã được sửa đổi của code đó. Ông xem phần cứng bị khóa là vấn đề kinh doanh của nhà sản xuất. Trên thực tế, việc đổi license cũng gần như không thể, vì bản quyền kernel thuộc về hàng nghìn contributor và không có thỏa thuận chuyển nhượng bản quyền để sử dụng. Kernel dùng GPL-2.0-only, nên code chỉ được cung cấp theo GPLv3 không thể được merge.

Linux kernel là monolithic kernel hay microkernel?

Đây là monolithic kernel có loadable module. Driver và filesystem chạy trong address space của kernel, còn lsmod hiển thị những thành phần đang được load. Mô hình này tăng tốc độ nhưng cũng tăng phạm vi ảnh hưởng khi có lỗi: một module lỗi có thể làm toàn bộ máy bị kernel panic, trong khi microkernel chỉ làm mất một process. Khác biệt này đã giảm từ năm 1992 nhờ filesystem FUSE chạy trong user space và các chương trình eBPF được kernel kiểm tra trước khi chạy.

Mainline, stable và longterm kernel khác nhau thế nào?

Mainline là tree của Torvalds, được release sau mỗi 9 đến 10 tuần, và feature mới được đưa vào đây trước. Stable lấy bản release mainline mới nhất rồi nhận các bản sửa lỗi trong vài tuần. Nhánh longterm tiếp tục nhận bản sửa lỗi trong nhiều năm, và các distribution dùng những nhánh này để build kernel. kernel.org liệt kê các nhánh longterm hiện tại cùng ngày dự kiến end-of-life của từng nhánh.

Linux kernel có nhận code do AI viết không?

Có, theo policy được cam kết vào tháng 12 năm 2025. Tool phải được ghi trong tag Assisted-by:, AI agent không được thêm dòng Signed-off-by, và code được tạo ra phải tương thích với GPL-2.0-only. Người submit phải ký xác nhận, nghĩa là họ đã review patch và chịu trách nhiệm về patch đó theo Developer Certificate of Origin.

Nên chạy phiên bản kernel nào trên server?

Trong hầu hết trường hợp, hãy dùng phiên bản do distribution của bạn duy trì. Distribution kernel là một nhánh longterm kèm các bản sửa lỗi được backport và quy trình kiểm thử của vendor. Đây cũng là phiên bản mà image của provider và thỏa thuận hỗ trợ của bạn giả định sẽ sử dụng. Chỉ build kernel mainline mới hơn khi bạn cần một driver hoặc feature cụ thể. Trước khi quyết định dùng nhánh mới, hãy kiểm tra ngày end-of-life của nhánh đó.