On Fri, Aug 9, 2024 at 3:33 AM Peter Chubb via Devel
This kind of thing is doable, or rather will be doable, by swapping out modules. Although the _architecture_ is static, not all the modules need to be runnable at any one time. In LionsOS one will be able to instantiate template PDs that can run a range of different payloads loaded at run-time, to allow a degree of dynamism.
We have a student working on the hotplug problem at the moment. But it's unclear, in the general case, what should happen when something appears in, or disappears from, the system. Utimately it's going to be up to the system designer to design something that works for each system.
For example, if you remove a storage device (SDHC card, or USB stick). Your alternatives are: -- discard all in-flight requests for the device, unmount any filesystems etc. -- Mark the device as 'gone'; but if there are any in-flight requests, or if any new requests get queued, ask the GUI to pop up something asking for reinsertion of the device (like AmigaDOS did) -- something else I haven't thought of...
In whatever case, you need system policy to decide what to do, and code to implement it.
I expect the handheld device _will_ eventually be a target for a LionsOS system, but there's a fair bit of work to do.
In the near term, there will have to be more device drivers and virtualisers in the sDDF; more higher-level components in LionsOS itself; and the template PDs that are currently being worked on here by an undergraduate student.
Even with this limited form of dynamism it's still going to be rather limiting. I'd think it would be limited to be more or less like a software secure enclave type of thing, or a fixed set of VMs for different security levels. Applications are still likely going to be run in Linux VMs with all of the issues of Linux. Running Linux VMs and a relatively closed set of secure applications isn't going to magically fix all of Linux's issues. IMO a better approach for general-purpose OSes is to forgo verification and go with something more akin to QNX architecturally (of course, with a centralized security model rather than QNX's security model that requires origin servers to verify permissions). Even a non-verified QNX-like system is going to be far more secure, stable, and extensible than just about any kind of Linux system.