Lịch sử Linux kernel: những quyết định còn hiệu lực

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

Lịch sử Linux kernel bắt đầu từ version 0.01 vào tháng 9 năm 1991 và kéo dài đến series 7.x đang boot trên các server hiện nay. Danh sách các bản release là phần ít đáng chú ý nhất. Một số ít quyết định đã định hình hệ thống này, và mỗi quyết định vẫn để lại hệ quả trên một máy chủ bạn thuê chiều nay. Lý do cần một kernel mới vào năm 1991 nằm trong câu chuyện dài hơn về Unix, việc cấp phép của AT&T và vụ kiện khiến BSD bị đình trệ.

Ngày tháng và số phiên bản trong phần này lấy từ kernel.org và lịch sử release do dự án công bố. Tình trạng hiện tại tính đến tháng 8 năm 2026: 7.0 được phát hành vào ngày 12 tháng 4 năm 2026, 7.1 vào ngày 14 tháng 6 năm 2026, và 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 licence do Torvalds tự viết. Licence này yêu cầu phải phân phối source, đồng thời 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, software được phát hành trên floppy disk, và việc sao chép rồi gửi floppy disk cũng tốn tiền. Điều khoản đó khiến việc phát hành một bản Linux thương mại là không thể.

Ông đã thay đổi licence. Việc chuyển sang GNU General Public License (GPL) được công bố trong release notes 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 được xây dựng sau này trên Linux đều dựa trên thay đổi đó.

Kernel chỉ dùng GPL version 2 và chưa bao giờ chuyển sang version 3. Torvalds từ chối 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 một thiết bị phát hành kèm GPL code cũng phải chấp nhận bản code đã được sửa đổi. Ông xem hardware bị khóa là vấn đề kinh doanh riêng của nhà sản xuất. Năm 2017, các kernel developer đã công bố Kernel Enforcement Statement. Văn bản 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 vẫn giữ licence, thay vì mất licence vĩnh viễn ngay khi có vi phạm đầu tiên.

Trên server, điều này dẫn đến 2 hệ quả. Kernel binary mà bạn boot có kèm quyền nhận source 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 copyright trong kernel cũng nêu rõ licence không áp dụng cho user program sử dụng các kernel service thông qua system call thông thường. Đây là lý do proprietary database và monitoring agent có thể được phát hành cho Linux mà không vi phạm licence. Licence 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 cho server.

Vì sao kernel nguyên khối vẫn 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ó quyền đặc biệt, là thiết kế của thập niên 1970. Còn microkernel, trong đó các thành phần này chạy như những process thông thường, mới là hướng đi của 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 được 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. 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 giải quyết bằng một phương án dung hòa. Linux không bao giờ trở thành microkernel. Thay vào đó, nó có loadable kernel module: các object file có thể chèn vào kernel đang chạy rồi gỡ ra, nhờ đó driver có thể được phát hành tách khỏi kernel binary.

lsmod | head
modinfo virtio_net | head -5

lsmod liệt kê những module đ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 đi của disk và network nằm trong các 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. Kernel chỉ thông báo phần cứng mới. Một daemon trong user space quyết định load module nào và đặt tên cho device ra sao. Đây là cách việc quản lý device dần nằm trong init system, đồng thời là một phần lý do systemd trở nên khó tránh khỏi.

Module đem lại tính linh hoạt đó mà không phải chịu chi phí của thiết kế microkernel. Cô lập driver trong process riêng đồng nghĩa với việc phải trả chi phí context switch và gửi 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 chịu là điều cần tính đến: module chạy với đầy đủ quyền của kernel. Vì vậy, module lỗi có thể làm sập toàn bộ máy thay vì chỉ làm hỏng một process. Vấn đề này thể hiện rõ nhất với các module ngoài tree. Driver của vendor không nằm trong mainline phải được build lại cho từng kernel mới. DKMS thực hiện việc đó trong lúc upgrade. Nếu quá trình build thất bại, device sẽ đơn giản là biến mất sau lần reboot.

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

Linux 2.0 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, gọi 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 mã kernel. Vì vậy, CPU thứ hai chỉ giúp ích cho workload xử lý 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 phía sau cùng một lock.

Việc loại bỏ lock này mất mười lăm năm. Các phần còn lại sử dụng lock được chuyển sang cơ chế locking có độ chi tiết cao hơn, chủ yếu do Arnd Bergmann thực hiện, và 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 plan 4 vCPU hiện nay không có gì đặc biệt. Tuy nhiên, nó 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ên lịch cho các thread, còn hypervisor lên lịch cho kernel của bạn. Chạy top rồi đọc trường %st. Steal time là thời gian CPU mà kernel của bạn đã sẵn sàng sử dụng nhưng host cấp cho guest khác, nên không có thao tác tuning nào bên trong kernel có thể lấy lại thời gian đó.

Vì sao dòng 2.6 thay đổi cách build kernel

Trước 2.6, số phiên bản được chia thành các cặp. Số thứ hai chẵn biểu thị một dòng ổn định (2.4), còn số lẻ biểu thị dòng phát triển (2.5). 2.4 được phát hành vào ngày 4 tháng 1 năm 2001 và 2.6 vào ngày 17 tháng 12 năm 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 họ backport các bản sửa lỗi. Hai vendor cùng phát hành "2.4" có thể cung cấp các kernel cách nhau hàng nghìn patch.

Sau 2.6, mô hình phân tách này bị loại bỏ. Mainline hiện mở một merge window kéo dài khoảng hai tuần, tiếp 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 rõ. Nửa còn lại của mô hình xuất hiện vào ngày 4 tháng 3 năm 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ỉ chứa bản sửa lỗi cho 2.6.11, do Greg Kroah-Hartman và Chris Wright duy trì. Stable tree chỉ nhận bản sửa lỗi và từ chối 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, đó là lý do 7.0 xuất hiện sau 6.19 vào tháng 4 năm 2026. Điều quan trọng đối với server là distribution của bạn đang theo dõi branch nào và branch đó còn nhận được bản sửa lỗi hay không.

Git ra đời vào tháng 4/2005 sau sự cố BitKeeper

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

Mọi việc đổ vỡ vào tháng 4/2005, sau khi Andrew Tridgell trình diễn một chương trình có thể giao tiếp với các repository BitKeeper. BitMover cho rằng đó là reverse engineering và rút licence miễn phí. Kernel mất hệ thống quản lý 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/2005. Torvalds công bố git vào ngày 6 tháng 4. Đến ngày 7 tháng 4, git đã tự quản lý chính nó, nghĩa là lịch sử của chính git đã được lưu trong git. Lần merge đầu tiên từ nhiều branch diễn ra vào ngày 18 tháng 4. Tháng 6/2005, git đã quản lý việc phát hành phiên bản 2.6.12. Không lâu sau, Torvalds giao việc bảo trì cho Junio Hamano rồi quay lại làm kernel.

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

Mô hình LTS cam kết điều gì và không cam kết điều gì

Mainline không phải bản bạn sẽ chạy. Một bản release mainline sẽ được 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 release. Các nhánh longterm, thường được viết là LTS, tiếp tục nhận bản sửa lỗi trong nhiều năm. Đây là những 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 cùng phiên bản này. Nhánh đó được duy trì đến tháng 2 năm 2016, hơn 6 năm sau khi xuất hiện. Red Hat còn duy trì kernel dựa trên 2.6.32 bằng các backport riêng cho đến khi RHEL 6 kết thúc vòng đời vào năm 2020. Việc tái tạo miễn phí thời gian hỗ trợ kéo dài cả thập kỷ đó là toàn bộ lý do CentOS tồn tại rồi được Rocky Linux và AlmaLinux thay thế.

Cam kết này đã thay đổi nhiều lần. Ban đầu là 2 năm, sau đó một số nhánh được hỗ trợ 6 năm. Năm 2023, các maintainer của stable giảm mặc định trở lại 2 năm, vì việc backport 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. Khung hiện tại kéo dài từ 3 đến 6 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
  }
]

kernel.org liệt kê 6 nhánh longterm tính đến tháng 8 năm 2026. 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 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ị ngừng duy trì. 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à interim release trên server. Đây cũng là điều thực sự thay đổi bên dưới hệ thống 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 in ra một giá trị tương tự 6.8.0-51-generic. Đây là phiên bản upstream làm nền cộng với các backport riêng của bản phân phối. Vì vậy, số phiên bản cho biết nhánh bắt đầu từ đâu, không cho biết nhánh đó chứa những bản sửa lỗi nào. Vì lý do này, các scanner đánh giá kernel chỉ dựa trên chuỗi phiên bản thường cảnh báo nhầm đối với kernel của bản phân phối.

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

Hiện có 2 cuộc 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 kernel như một thành phần hạ tầng từ phiên bản 6.1 vào tháng 12 năm 2022. Đến phiên bản 7.0, nhãn experimental được gỡ bỏ. Vì vậy, các ngôn ngữ cốt lõi của kernel hiện là C, assembly và Rust, đồng thời quá trình build không còn cần nightly compiler. Tranh chấp nằm ở khâu bảo trì. Một maintainer C thay đổi một interface có thể làm hỏng các Rust binding mà họ không đọc, và vấn đề đang được tranh luận là ai chịu trách nhiệm sửa chúng.

Cuộc tranh luận thứ 2 liên quan đến đóng góp do AI hỗ trợ. Sasha Levin đề xuất một policy vào tháng 7 năm 2025, sau khi ngày càng 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 tài liệu coding assistant. AI agent không được thêm tag Signed-off-by, vì dòng đó 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ì tool không phải là tác giả. Code được tạo 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. Tạo một patch chỉ mất vài giây, còn 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ự mất cân bằng đó. Đ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ê

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

FAQ

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

Torvalds đã phản đối GPLv3 vào năm 2007, chủ yếu vì yêu cầu chống tivoisation. Yêu cầu này buộc thiết bị phát hành GPL code cũng phải chấp nhận phiên bản đã sửa đổi của code đó. Ông xem hardware bị khóa là vấn đề kinh doanh của nhà sản xuất. Việc đổi license trên thực tế cũng gần như không thể, vì copyright của kernel thuộc về hàng nghìn contributor và không có thỏa thuận chuyển giao nào để sử dụng làm cơ sở. 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ó hỗ trợ loadable module. Driver và filesystem chạy trong address space của kernel, còn lsmod hiển thị những module đang được load. Mô hình này tăng tốc độ nhưng cũng tăng blast radius: một module lỗi có thể làm toàn bộ máy panic, trong khi microkernel chỉ làm mất một process. Sự khác biệt này đã giảm bớt từ năm 1992 nhờ filesystem FUSE chạy trong user space và các chương trình eBPF được kernel verify 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 sẽ xuất hiện ở đó trước. Stable lấy bản release mainline mới nhất rồi nhận bug fix trong vài tuần. Nhánh longterm tiếp tục nhận fix trong nhiều năm và là nền tảng để các distribution build kernel của họ. 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 khai báo 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 sign off, 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 gần như mọi trường hợp, hãy dùng phiên bản do distribution của bạn duy trì. Kernel của distribution là một nhánh longterm kèm các fix đượ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. Chỉ build kernel mainline mới hơn khi cần một driver hoặc feature cụ thể. Trước khi chọn nhánh mới, hãy kiểm tra ngày end-of-life của nhánh đó.