Giải thích cho comment ‘You are Not Expected to Understand This’ tai tiếng nhất giới Unix

Câu nói “You are Not Expected to Understand This” (Bạn Đáng Lẽ Ra Không Nên Hiểu Cái Này) có lẽ là comment nổi tiếng nhất trong lịch sử Unix.

Tại hội nghị Systems We Love ở San Francisco, nhà nghiên cứu hệ thống Arun Thomas giải thích với khán giả chính xác họ “đáng lẽ không nên hiểu” cái gì.

Giáo sư khoa học máy tính Ozan Onay, ngồi ở hàng ghế khán giả, cho biết đây là “phần nói chuyện tôi thích nhất”, và viết trên blog cá nhân “Không chiếc hộp nào nên là hộp đem cả, ngay cả khi Dennis Ritchie nói ‘ok’!”

Thomas mở đầu buổi nói chuyện của mình bằng “Tôi yêu hệ thống — đặc biệt là các hệ điều hành.” Nhưng thậm chí đến anh cũng phải trầm trồ trước sự phổ biến của source code comment 42 tuổi trên Unix này: “Mọi người bắt đầu mặc áo thun, áo len, đồ ngủ có viết ‘You are not expected to understand this’, và biến thành trào lưu trong giới hacker luôn.” Kể từ đó, comment này nổi tiếng đến độ ai cũng biết.

Đoạn code comment này ban đầu xuất hiện trong hệ điều hành Sixth Edition Unix, để mô tả chuyển đổi ngữ cảnh (context switching) — hoặc, theo như Thomas, “Cơ chế cho phép time-sharing (chia sẻ thời gian) và multi-tasking (đa nhiệm)… Nói cách khác, là cách cho phép máy tính được sử dụng đồng thời bởi nhiều người dùng và nhiều ứng dụng cùng một lúc.

Về cơ bản, context là là một tổ hợp stack pointer và register cho phép các process trong Unix được liên tục tạm dừng và khôi phục. “Một tính năng tuyệt vời thời đó, và khả năng hỗ trợ time-sharing của Unix là một trong nhiều lý do quan trọng giúp hệ điều hành này thành công. Đây chính là một bước nhảy lớn về mặt khả dụng”. Thomas nói thêm “Nhiều thay đổi đã diễn ra trong những năm qua, Nhưng thiết kế tổng quan về cơ bản vẫn giữ nguyên.”

Thomas nhắc về trang web  “Comment về comment” của chính nhà đồng sáng lập của Unix Dennis Ritchie với khán giả:

“Câu nói thường được trích dẫn để chỉ trích chất lượng và số lượng của comment trong các công báo nghiên cứu Bell Labs của Unix. Tôi cho rằng, đây nhìn chung không phải là cái nhìn công bằng, mà nói đúng hơn là phi lý… chúng tôi đã cố gắng giải thích mọi thứ đang diễn ra. ‘Bạn đáng lẽ không nên hiểu được cái này’ dự định là để nêu bật tinh thần ‘Đoạn này sẽ không nằm trong bài kiểm tra’, chứ không phải diển tả một thách thức vô lý.” 

Ritchie xem đây chỉ như một mẩu chuyện vui trong lịch sử geeky lập dị. (hơn nữa, anh cũng giải thích lý do tại sao đôi khi lệnh mv lại trả lại diagnostic message “values of β will give rise to dom!”). Nhưng Ritchie đã biết rõ rằng comment năm 1975 của mình từng thu hút cả một giáo phái theo sau:

Anh viết: “Tôi thậm chí từng nhận được hai chiếc áo nỉ có trích lại comment này”.

Thomas từ đó kế tiếp câu chuyện. “Ritchie cũng chia sẻ thêm một chuyện khá hay là hóa ra đoạn code cũng khá là nhiều bug, và người viết Unix cũng chả hoàn toàn hiểu mình viết gì nữa là.”

“Vậy, cốt lõi của câu comment này là context switching cũng có thể trở nên rất khó khăn, ngay cả đối với người viết ra Unix.”

Unix v6 ra mắt năm 1975. “Nó có khoảng 9,000 dòng code,” Thomas chỉ ra, “nhỏ xíu, học một khóa đại học là xong.” Anh nhớ lại năm 1979, AT&T thay đổi điều khoảng cấp phép cho Unix để cho phép chỉ người có sở hữu license chính thức, được nghiên cứu đoạn code.

Nhưng toàn bộ mã nguồn của phiên bản 6 đã được phát hành trong cuốn sách do John Lions (giáo sư Đại Học NewSouth Wales viết), cùng với những nhận xét của ông, khiến cuốn sách nổi tiếng bất thường. Thomas cho khán giả biết: “Mọi người liên tục đi photo bản photo,” nhấn mạnh đây là một hiện tượng thậm chí cuối cùng còn được lên bìa sách:

Trang Wikipedia của cuốn sách chỉ ra “đây chính là cuốn sách bị sao chép nhiều nhất trong lịch sử khoa học máy tính”

“Tôi từng nói về chủ đề này tại Papers We Love Boston, mà có một khán giả xuất hiện với bản sao trái phép của Lions. Cảm giác thật tuyệt khi thấy vẫn có người còn giữ và trân trọng những thứ này.”

Nhưng cũng chính sự nổi tiếng của cuốn sách mà comment tưởng như tầm thường của Ritchie mới có cơ hội đến với cộng đồng.

Như vậy, cái gì mà phức tạp đến mức mã nguồn “không ngờ” là mình sẽ hiểu được? Thomas nhanh chóng nhảy vào cách Unix xác định một process — với một virtual processor và các memory adress spaces (không gian địa chỉ bộ nhớ) liên quan — và giải thích với khán giả phần cứng tham gia vào quá trình này. Nhiệm vụ của CPU là cách ly phần bộ nhớ cho các process, đồng thời theo dõi xem các hoạt động đặc quyền có được cho phép hay không, và hỗ trợ interrupt và exception.

Chắc chắn, sẽ đến lúc cần lưu CPU context (để restore sau này) mỗi khi các chuyển đổi (switch process). Thomas cho khán giả biết: “Chuyện này sẽ tiếp diễn liên tục. Các precess sẽ bị context-switch ra, và rồi lại context-switch vào.” Khi một phần CPU time được dùng hết, hoặc khi có tín hiệu interrupt, lỗi page, hoặc system call, context sẽ được chuyển đổi. “Các processes liên tục được tung hứng.”

“Bạn có thể hình dung Hệ Điều Hành như mấy anh bảo kê ở CPU club vậy: Nếu bạn quá to mồm, bạn sẽ bị đuổi ra. Và nếu có anh VIP nào đó bao nguyên khu, bạn cũng bị đá đi luôn, nhưng hôm sau nếu có thể bạn vẫn quay lại được.”

“You can think of the OS as the bouncer at Club CPU: if a VIP comes in and buys up the place, you’re out.” — @arunthomas #systemswelove

— Systems We Love (@SystemsWeLove) December 14, 2016

Còn nếu đi sâu hơn cả mớ bòng bong này xảy ra như thế nào lại rắc rối hơn một chút: CPU và kernel lưu trữ context của process đầu tiên trong một cấu trúc dữ liệu; xác định process ưu tiên cao nhất kế tiếp để thực hiện quyết định sắp xếp thứ tự như thế nào, rồi sau đó phục hồi context cho process tiếp theo.

Để hoàn toàn làm rõ comment của Ritchie, Thomas tiếp tục nêu ra một số đoạn trong mã nguồn Unix trước khán giả, đưa họ quay trở lại năm 1975.

Lúc này khán giả được thấy cách routine swtch() call ra subroutine **savu()** để lưu context (có trách nghiệm lưu context trong cấu trúc dữ liệu kernel tên **u_rsav()**). Các phần context khác sẽ được lưu trữ tại nơi khác. Sau đó subroutine **retu()** sẽ khôi phục một vài context tiếp theo, trong khi đó subroutine **sureg()** giúp chuẩn bị virtual address space của nó. “Toàn bộ chi tiết đều có trong Lions — và khá là phức tạp — nhưng đọc cũng hay.”

Nhưng các bạn cần nhớ điều này — các bạn đáng lẽ là không thể hiểu được đâu!

Đoạn code Unix V6 gốc cho **swtch()** còn chứa một số comment “thẳng thừng” hơn nữa:

/* Remember stack of caller
/* Search for highest-priority runnable process
/* Switch to stack of the new process and
/* set up his segmentation registers.

Nhưng đến cùng, comment gây sốt ưa thích của cộng đồng nhanh chóng hạ nhiệt chỉ sau vài năm, khi đoạn code cho context-switch được viết lại trong Unix v7 năm 1979. Đến ngày nay, bạn vẫn có thể tìm được một switching subroutine trong FreeBSD, nhưng mà lại có tên là **cpu_switch()** bây giờ hoạt động này đã trở nên đặc trưng cho CPU rồi — và scheduling code bị chuyển cho **sched_switch()** (độc lập với hệ thống).

Như vậy, chúng ta đang làm việc dựa trên những tác phẩm của những “siêu nhân lập dị” đã đi trước chúng ta. Thomas nhắc nhở khán giả rằng Unix hiện đại, như FreeBSD ngày nay, lại phức tạp hơn — ví dụ như threads và dynamic linking — nhưng “độ trừu tượng của hệ thống nhìn chung vẫn giữ nguyên.” Các thuật toán cho việc scheduling cũng đã trở nên cao cấp hơn, và bức tranh phần cứng cũng hoàn toàn khác hẳn với những ngày PDP-11. Đến cùng, “Các hệ điều hành hiện đại về cơ bản thực hiện timesharing giống như cũ, bằng cách sử dụng process abstraction và context switching.”

Phân chia sẻ của Thomas đã cho khán giả thấy được những công việc tưởng chừng đơn giản ngày nay lại khó nhằn đến mức nào trong bối cảnh 1975. Anh chia sẻ với khán giả San Francisco: “Timesharing thực hiện không dễ — phần cứng thì rắc rối — và tôi hi vọng các bạn phần nào hiểu được những khó khăn của chúng tôi.”

“Ngay cả khi tôi thất bại, và không thể vượt qua được tầm quan trọng của process abstraction và context switching, ít nhất bạn sẽ hiểu được chiếc áo thun mà tôi đang mặc.”