thảo luận [Tâm sự] Nghề dev Linux kernel ở Việt Nam

Chào bác @PhuThoDien, em xem được thread này từ lâu rồi cơ mà bây giờ mới mò vào lại. Hiện tại em là sinh viên năm 2 và thấy bản thân có thể nói là có một sự hứng thú to lớn với hệ điều hành, kernel và các thành phần của nó. Bây giờ em đang tự học các concept của hệ điều hành thông qua cuốn OSTEP và dự định sau đó sẽ đi đọc hiểu thử code một cái kernel nhỏ là xv6 rồi tiến tới kernel linux.
Mò lại vào thread thì thấy được cái vid này của bác.
Dù không hiểu gì lắm, có thể là cái bác giảng trong vid hơi xa quá so với tầm hiểu biết hiện tại của em nhưng công nhận xem rất là cuốn. Đến cái phần bác demo led rồi nói về cái địa chỉ vật lí phải được ảo hoá bởi hệ điều hành chứ mình không dùng trực tiếp được mới gọi là có tí liên hệ với kiến thức hiện tại.
Xin hỏi bác một tí là nếu em tiếp tục học sâu hơn về kernel, hệ điều hành thì cơ hội việc làm cho fresher, junior trong lĩnh vực kernel và linux này thế nào ạ ? Vì có vẻ những thứ low-level thế này không phổ thông trong thị trường việc làm theo em tìm hiểu.
 
Chào bác @PhuThoDien, em xem được thread này từ lâu rồi cơ mà bây giờ mới mò vào lại. Hiện tại em là sinh viên năm 2 và thấy bản thân có thể nói là có một sự hứng thú to lớn với hệ điều hành, kernel và các thành phần của nó. Bây giờ em đang tự học các concept của hệ điều hành thông qua cuốn OSTEP và dự định sau đó sẽ đi đọc hiểu thử code một cái kernel nhỏ là xv6 rồi tiến tới kernel linux.
Mò lại vào thread thì thấy được cái vid này của bác.
Dù không hiểu gì lắm, có thể là cái bác giảng trong vid hơi xa quá so với tầm hiểu biết hiện tại của em nhưng công nhận xem rất là cuốn. Đến cái phần bác demo led rồi nói về cái địa chỉ vật lí phải được ảo hoá bởi hệ điều hành chứ mình không dùng trực tiếp được mới gọi là có tí liên hệ với kiến thức hiện tại.
Xin hỏi bác một tí là nếu em tiếp tục học sâu hơn về kernel, hệ điều hành thì cơ hội việc làm cho fresher, junior trong lĩnh vực kernel và linux này thế nào ạ ? Vì có vẻ những thứ low-level thế này không phổ thông trong thị trường việc làm theo em tìm hiểu.
Hi em, anh tập trung trả lời vào phần cơ hội việc làm nhé. Học về Linux kernel thì ở VN có thể làm trong 2 mảng chính là embedded và security. Còn nhiều mảng nữa nhưng chủ yếu nằm ở nước ngoài nên anh ko đề cập.
Giữa 2 mảng embedded và security thì embedded hiện tại đang là xu hướng, lượng job nhiều và lương ổn. Đơn giản là tại thời điểm này thị trường bị down trend nhưng embedded vẫn tuyển internship và fresher.
Embedded thì phù hợp cho các bạn có base về điện tử, anh đoán là em ko có cái này. Còn Security thì hợp với các bạn bên cntt. Thực ra học sâu về kernel là đã có một phần kiến thức về security rồi, có thể đi xin việc về mảng này được.
Như anh thấy ở VN có VCS tuyển khá nhiều intern và fresher, em có thể chủ động liên hệ họ để hỏi yêu cầu đầu vào, từ đó lên kế hoạch học tập.
Nếu muốn đi xa về mảng này thì nên xác định phải làm cho nước ngoài, anh hiện tại cũng phải làm remote, mảng này ở VN mình có trình độ khá yếu, có khoảng cách rất lớn so với các nước phát triển.
 
Hi em, anh tập trung trả lời vào phần cơ hội việc làm nhé. Học về Linux kernel thì ở VN có thể làm trong 2 mảng chính là embedded và security. Còn nhiều mảng nữa nhưng chủ yếu nằm ở nước ngoài nên anh ko đề cập.
Giữa 2 mảng embedded và security thì embedded hiện tại đang là xu hướng, lượng job nhiều và lương ổn. Đơn giản là tại thời điểm này thị trường bị down trend nhưng embedded vẫn tuyển internship và fresher.
Embedded thì phù hợp cho các bạn có base về điện tử, anh đoán là em ko có cái này. Còn Security thì hợp với các bạn bên cntt. Thực ra học sâu về kernel là đã có một phần kiến thức về security rồi, có thể đi xin việc về mảng này được.
Như anh thấy ở VN có VCS tuyển khá nhiều intern và fresher, em có thể chủ động liên hệ họ để hỏi yêu cầu đầu vào, từ đó lên kế hoạch học tập.
Nếu muốn đi xa về mảng này thì nên xác định phải làm cho nước ngoài, anh hiện tại cũng phải làm remote, mảng này ở VN mình có trình độ khá yếu, có khoảng cách rất lớn so với các nước phát triển.
Cảm ơn anh đã trả lời. Cho em hỏi thêm nếu đi theo hướng security tức là mình phải học thêm các kiến thức bên an ninh mạng bên cạnh kernel đúng không ạ?
 
Cảm ơn anh đã trả lời. Cho em hỏi thêm nếu đi theo hướng security tức là mình phải học thêm các kiến thức bên an ninh mạng bên cạnh kernel đúng không ạ?
Cũng ko cần đâu em. Làm software development cho các phần mềm security thì kiến thức về hệ điều hành là đủ.
Làm vài năm ở VN rồi tìm cách làm trực tiếp các job về kernel development cho nước ngoài.
 
Hi em, anh tập trung trả lời vào phần cơ hội việc làm nhé. Học về Linux kernel thì ở VN có thể làm trong 2 mảng chính là embedded và security. Còn nhiều mảng nữa nhưng chủ yếu nằm ở nước ngoài nên anh ko đề cập.
Giữa 2 mảng embedded và security thì embedded hiện tại đang là xu hướng, lượng job nhiều và lương ổn. Đơn giản là tại thời điểm này thị trường bị down trend nhưng embedded vẫn tuyển internship và fresher.
Embedded thì phù hợp cho các bạn có base về điện tử, anh đoán là em ko có cái này. Còn Security thì hợp với các bạn bên cntt. Thực ra học sâu về kernel là đã có một phần kiến thức về security rồi, có thể đi xin việc về mảng này được.
Như anh thấy ở VN có VCS tuyển khá nhiều intern và fresher, em có thể chủ động liên hệ họ để hỏi yêu cầu đầu vào, từ đó lên kế hoạch học tập.
Nếu muốn đi xa về mảng này thì nên xác định phải làm cho nước ngoài, anh hiện tại cũng phải làm remote, mảng này ở VN mình có trình độ khá yếu, có khoảng cách rất lớn so với các nước phát triển.
Chỗ này nên làm rõ một chút, như mình thấy Linux embedded phù hợp với các bạn học điện tử vì học điện tử ra mà làm thuần software thì bất lợi, khó cạnh tranh với đám học IT chứ ko phải có base điện tử mới phù hợp làm embedded. Embedded làm việc với phần cứng nhưng bản chất vẫn là viết code, vẫn là làm software
Chia sẻ kinh nghiệm cá nhân thì mình ko có base điện tử, đã từng làm nhúng(linux) trong 3 năm(giờ bỏ rồi) và ko gặp vấn đề gì về điện tử hết, mấy cái như GPIO, I2C, etc. ban đầu chả biết là gì thì hỏi đồng nghiệp hoặc gg rồi xem doc tí là làm dc hết, chỉ cần hiểu nguyên tắc hoạt động cơ bản và set đúng địa chỉ là được. Ngược lại thấy các bạn học điện tử lại thiếu một số kiến thức nền tảng về phần mềm, là một điểm yếu lớn hơn:doubt:
 
Chỗ này nên làm rõ một chút, như mình thấy Linux embedded phù hợp với các bạn học điện tử vì học điện tử ra mà làm thuần software thì bất lợi, khó cạnh tranh với đám học IT chứ ko phải có base điện tử mới phù hợp làm embedded. Embedded làm việc với phần cứng nhưng bản chất vẫn là viết code, vẫn là làm software
Chia sẻ kinh nghiệm cá nhân thì mình ko có base điện tử, đã từng làm nhúng(linux) trong 3 năm(giờ bỏ rồi) và ko gặp vấn đề gì về điện tử hết, mấy cái như GPIO, I2C, etc. ban đầu chả biết là gì thì hỏi đồng nghiệp hoặc gg rồi xem doc tí là làm dc hết, chỉ cần hiểu nguyên tắc hoạt động cơ bản và set đúng địa chỉ là được. Ngược lại thấy các bạn học điện tử lại thiếu một số kiến thức nền tảng về phần mềm, là một điểm yếu lớn hơn:doubt:
Lĩnh vực nào cũng có người này người kia bác à, cái mình nói ở đây là dựa theo tỷ lệ số đông.
 
Lĩnh vực nào cũng có người này người kia bác à, cái mình nói ở đây là dựa theo tỷ lệ số đông.
Thím nói cơ bản ko sai, nhưng đoạn này đang tư vấn cho bạn kia, cách diễn đạt của thím có thể khiến bạn ấy nghĩ bản thân ko phù hợp làm embedded và bỏ qua hướng này:big_smile:
 
Chỗ này nên làm rõ một chút, như mình thấy Linux embedded phù hợp với các bạn học điện tử vì học điện tử ra mà làm thuần software thì bất lợi, khó cạnh tranh với đám học IT chứ ko phải có base điện tử mới phù hợp làm embedded. Embedded làm việc với phần cứng nhưng bản chất vẫn là viết code, vẫn là làm software
Chia sẻ kinh nghiệm cá nhân thì mình ko có base điện tử, đã từng làm nhúng(linux) trong 3 năm(giờ bỏ rồi) và ko gặp vấn đề gì về điện tử hết, mấy cái như GPIO, I2C, etc. ban đầu chả biết là gì thì hỏi đồng nghiệp hoặc gg rồi xem doc tí là làm dc hết, chỉ cần hiểu nguyên tắc hoạt động cơ bản và set đúng địa chỉ là được. Ngược lại thấy các bạn học điện tử lại thiếu một số kiến thức nền tảng về phần mềm, là một điểm yếu lớn hơn:doubt:
giờ bác chuyển sang mảng nào rồi ạ?
Em cũng thấy làm Embed Linux cũng ít gặp vấn đề về hardware, nhưng mà đụng đến mấy phần như phát triển thuật toán xử lí tín hiệu chắc bên điện tử sẽ lợi thế hơn
 
giờ bác chuyển sang mảng nào rồi ạ?
Em cũng thấy làm Embed Linux cũng ít gặp vấn đề về hardware, nhưng mà đụng đến mấy phần như phát triển thuật toán xử lí tín hiệu chắc bên điện tử sẽ lợi thế hơn
Giờ quay lại làm web,app rồi thím:byebye:
 
Chỗ này nên làm rõ một chút, như mình thấy Linux embedded phù hợp với các bạn học điện tử vì học điện tử ra mà làm thuần software thì bất lợi, khó cạnh tranh với đám học IT chứ ko phải có base điện tử mới phù hợp làm embedded. Embedded làm việc với phần cứng nhưng bản chất vẫn là viết code, vẫn là làm software
Chia sẻ kinh nghiệm cá nhân thì mình ko có base điện tử, đã từng làm nhúng(linux) trong 3 năm(giờ bỏ rồi) và ko gặp vấn đề gì về điện tử hết, mấy cái như GPIO, I2C, etc. ban đầu chả biết là gì thì hỏi đồng nghiệp hoặc gg rồi xem doc tí là làm dc hết, chỉ cần hiểu nguyên tắc hoạt động cơ bản và set đúng địa chỉ là được. Ngược lại thấy các bạn học điện tử lại thiếu một số kiến thức nền tảng về phần mềm, là một điểm yếu lớn hơn:doubt:
"kiến thức nền tảng về phần mềm" là dsa, oop hả anh. còn gì nữa ko để em học bổ sung với, em bên cơ khí mà giờ làm nhúng :D, ko có base kiến thức j liên quan luôn
 
"kiến thức nền tảng về phần mềm" là dsa, oop hả anh. còn gì nữa ko để em học bổ sung với, em bên cơ khí mà giờ làm nhúng :D, ko có base kiến thức j liên quan luôn
Một số kiến thức kỹ thuật nền tảng mà mình nghĩ dev ngành nào cũng cần biết, dù là nhúng hay ko:
  • Language: tối thiểu 1 ngôn ngữ, đương nhiên. Và nên biết thêm vài ngôn ngữ khác. Một số ý tưởng từ ngôn ngữ khác có thể áp dụng vào ngôn ngữ bạn đang sử dụng. Ví dụ đoạn dưới mình sẽ nhắc đến OOP. Nếu bạn chỉ biết mỗi C thì có lẽ sẽ hơi khó tiếp nhận tư duy OOP
  • Data structure and algorithm: ko nhiều trường hợp bạn phải tự implement một cái queue hay tree nhưng ít nhất bạn cần biết khi nào thì nên dùng cấu trúc dữ liệu nào, giải thuật nào. Và học cái này cũng giúp rèn luyện kỹ năng, tư duy lập trình nói chung
  • Networking: Thời đại này hầu như ko thiết bị nào làm việc một mình mà ko có kết nối ra ngoài. Ít nhất nên biết các giao thức phổ biến: HTTP, TCP, IP.
  • Cryptography: Ko làm chuyên gia bảo mật thì cũng cần biết cách bảo vệ hệ thống ở mức cơ bản. Chỗ này mình định nói là bảo mật nhưng bảo mật là thuật ngữ khá chung chung, kết hợp của cryptography, code, network. Ví dụ khi muốn truyền thông tin ra web server, nên chọn HTTP hay HTTPS? Dùng HTTPS có đủ an toàn cho kết nối của bạn ko? Cái này phải có kiến thức về Network và Cryptography
  • OS, computer architect: Làm Linux embedded chắc chắn phải biết rồi.
  • OOP: C ko được xây dựng với tư duy OOP nhưng nhiều phần code ở kernel được áp dụng tư tưởng OOP
  • Web: Web là một thành phần khá phổ biến trong một thiết bị nhúng, người dùng vào web để quản lý thiết bị. Ngoài ra nhiều trường hợp thiết bị của bạn tương tác với một web server do đội khác phát triển. Hiểu về cách web server hoạt động giúp bạn đưa ra giải pháp tổng thể tốt hơn cho cả 2 đội
  • Database: Riêng cái này mình hơi băn khoăn có nên đưa vào ko vì đây là kiến thức rất quan trọng của software nói chung nhưng có vẻ ko thực sự cần thiết cho nhúng
:big_smile:
 
Last edited:
T mới đọc được bài này.

Đại ý là scheduler nó sẽ scale theo số lượng CPUs. Càng nhiều CPUs thì tgian thực thi cho 1 task trước khi context switch càng lớn => giảm đc số lượng context switch, chạy hiệu quả hơn. Nhưng nó chỉ scale max là 8 CPUs, do hard code trong kernel.

Trong đây nhiều ông làm về kernel có thể confirm cái này đc k nhỉ.
 
T mới đọc được bài này.

Đại ý là scheduler nó sẽ scale theo số lượng CPUs. Càng nhiều CPUs thì tgian thực thi cho 1 task trước khi context switch càng lớn => giảm đc số lượng context switch, chạy hiệu quả hơn. Nhưng nó chỉ scale max là 8 CPUs, do hard code trong kernel.

Trong đây nhiều ông làm về kernel có thể confirm cái này đc k nhỉ.
hi bác theo em tìm hiểu cũng như đọc comment thì
1700371172681.png

cái sched_min_granularity .... liên quan đến thời gian chạy trước khi switching của từng process, nó sẽ được tính toán dựa trên số lượng cpu
Như ta thấy thì sched_latency tăng lên khi số lượng cores tăng lên nhưng không thể tăng lên mãi giới hạn là 8cores
Và đoạn hardcode 8cores này chỉ được dùng ở việc tính toán sched_latency ( và vài biến khác).
NÊN KHÔNG CÓ CHUYỆN schudler linux bị giới hạn ở 8 cores bác nhé, cái bị giới hạn ở đây là sched_latency... ( tỉ lệ thuận với số core)
bác có thể review thêm về đoạn hardcode ở link này
 
Last edited:
hi bác theo em tìm hiểu cũng như đọc comment thì
View attachment 2190814
cái sched_min_granularity .... liên quan đến thời gian chạy trước khi switching của từng process, nó sẽ được tính toán dựa trên số lượng cpu
Như ta thấy thì sched_latency tăng lên khi số lượng cores tăng lên nhưng không thể tăng lên mãi giới hạn là 8cores
Và đoạn hardcode 8cores này chỉ được dùng ở việc tính toán sched_latency ( và vài biến khác).
NÊN KHÔNG CÓ CHUYỆN schudler linux bị giới hạn ở 8 cores bác nhé, cái bị giới hạn ở đây là sched_latency... ( tỉ lệ thuận với số core)
bác có thể review thêm về đoạn hardcode ở link này
Thì ý của ông tác giả cũng là vậy mà, sched_latency sẽ tăng theo số lượng CPUs, nhưng chỉ đến 8 thôi, đó hard code. Vấn đề giờ cần quan tâm là tại sao có số 8 đó. Nếu bỏ nó đi thì sẽ có vấn đề gì.
 
Thì ý của ông tác giả cũng là vậy mà, sched_latency sẽ tăng theo số lượng CPUs, nhưng chỉ đến 8 thôi, đó hard code. Vấn đề giờ cần quan tâm là tại sao có số 8 đó. Nếu bỏ nó đi thì sẽ có vấn đề gì.
Em nghĩ là nếu tăng core không giới hạn thì latency nó lớn quá, mặc dù nhiều core thì nó cũng không realtime nữa.
Anyways em cũng chưa bao giờ sửa code r test số 8 đó bao h :)))
 
Em nghĩ là nếu tăng core không giới hạn thì latency nó lớn quá, mặc dù nhiều core thì nó cũng không realtime nữa.
Anyways em cũng chưa bao giờ sửa code r test số 8 đó bao h :)))
Nói chung để cố định con số 8 có vẻ k được make sense cho lắm. Vấn đề bây giờ cần xem xét là scale ntn. Đóng thẳng linear hoặc log cũng chưa chắc hợp lý, nói chung cái này phải thử nghiệm, nghiên cứu.
 
Nói chung để cố định con số 8 có vẻ k được make sense cho lắm. Vấn đề bây giờ cần xem xét là scale ntn. Đóng thẳng linear hoặc log cũng chưa chắc hợp lý, nói chung cái này phải thử nghiệm, nghiên cứu.
Nếu ko phải số 8 thì sao bác, ví dụ 128 core latency nó lên tới 100ms cứ cho là có 128 process chạy song song ko cần switch đi, vậy process thứ 129 thời gian switch lên tới 100ms thì còn realtime ko?
Em thấy limit lại vậy là vậy là hợp lí rồi
 
Nếu ko phải số 8 thì sao bác, ví dụ 128 core latency nó lên tới 100ms cứ cho là có 128 process chạy song song ko cần switch đi, vậy process thứ 129 thời gian switch lên tới 100ms thì còn realtime ko?
Em thấy limit lại vậy là vậy là hợp lí rồi
Tại sao 8 lại hợp lý? Sao k phải là 1 con số khác lớn hơn chẳng hạn?
Hiện tại chỉ đơn giản là ông kia tìm ra đc 1 chỗ mà ổng và nhiều ng khác nghi ngờ rằng có thể improve đc. Còn improve ntn thì cần phải thử nghiệm nhiều.
Phàm là những cái liên quan đến performance thì k nên phỏng đoán.
 
Tại sao 8 lại hợp lý? Sao k phải là 1 con số khác lớn hơn chẳng hạn?
Hiện tại chỉ đơn giản là ông kia tìm ra đc 1 chỗ mà ổng và nhiều ng khác nghi ngờ rằng có thể improve đc. Còn improve ntn thì cần phải thử nghiệm nhiều.
Phàm là những cái liên quan đến performance thì k nên phỏng đoán.
Nấy bro muốn biết đúng sai thì Đọc design của cpu mà mình sài đi chắc có thông tin. Mọi thuật toán nhúng bắt đầu từ datasheet của hardware .
 
Last edited:
Chào các bác, e cũng làm nhúng dc 2 năm, nhảy dự án loạn xì ngầu nên cũng trải qua kha khá, rtos có, linux driver cũng có, autosar rồi luôn, bây h chuyển sang vxworks. Hệt như bác Phú e cũng có ước mơ là dc làm trong core của Linux kernel, nhưng mà chưa biết bắt đầu từ đâu. Cảm ơn bác vì chuỗi bài post đầy cảm hứng nhiều thông tin bổ ích.
 
Back
Top