Products > Programming
Future Software Should Be Memory Safe, says the White House
SiliconWizard:
https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/press-release-technical-report/
DiTBho:
these days, Linus is discussing two things, well three things ...
* more Rust support for more drivers written in Rust
* micro kernel approach for linux, with a userspace scheduler already written as proof of concept
* development languages for future kernels must be memory safe, because with multi core and modern features we have already reached the point of no return in term of kernel complexity
(
oh, and from how some have responded - my speculation - it also seems that many Linux developers ...
... have now reached retirement age, so they would like to make way for younger people
mumble ... :-//
)
tggzzz:
"Science Engineering progresses one funeral at a time".
https://en.wikipedia.org/wiki/Planck%27s_principle
newbrain:
--- Quote from: DiTBho on March 01, 2024, 07:37:32 am ---
* micro kernel approach for linux, with a userspace scheduler already written as proof of concept
--- End quote ---
Wow, I did not see this coming.
So Tanenbaum had a point, in the end (others were proven wrong by history).
It won't be an easy transition, quite the radical architectural change.
DiTBho, do you have some good sources? DDG only return stuff about the original T-T debate...
DiTBho:
February 2024, Andrea Righi has started a blog "Writing a Scheduler for Linux in Rust that runs in user-space" series on writing a user-space CPU scheduler with the BPF-based extensible scheduler class:
".select_cpu() implements the logic to assign a target CPU to a task that wants to run, typically you have to decide if you want to keep the task on the same CPU or if it needs to be migrated to a different one, for example if the current CPU is busy; if you can find an idle CPU at this stage there's no reason to call the scheduler, the task can be immediately dispatched here.
see here :o :o :o
Navigation
[0] Message Index
[#] Next page
Go to full version