Interesting! So in the case of the device I’ve got here with privacy switches, my drivers would detect the removal of the modem and respond by dropping queued packets? Or some other mechanism, depending.
> On Aug 9, 2024, at 5:30 AM, Peter Chubb <peter.ch...@unsw.edu.au> wrote: > > >> >>>>>> "Isaac" == Isaac Beckett <isaactbeck...@gmail.com> writes: > > Isaac> I was looking at LionsOS docs recently, and noted it is meant > Isaac> for static systems with no support for changing hardware at > Isaac> runtime. This is less of a problem for phones and other > Isaac> handhelds given they generally keep the same hardware > Isaac> throughout their service life, but I was concerned about > Isaac> peripheral support. What if I want to be able to connect an > Isaac> external display to a phone or tablet running a LionsOS based > Isaac> userspace? Or I have privacy switches on the device that > Isaac> physically disconnect components such as the modem or camera > Isaac> assembly? > > 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. > > -- > Dr Peter Chubb https://trustworthy.systems/ > Trustworthy Systems Group CSE, UNSW > Core hours: Mon 8am-3pm; Wed: 8am-5pm; Fri 8am-12pm. _______________________________________________ Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems
