Hi Andrew, Thank you for your project. I will check out the root task in your project, that is what I was looking for. This might be a silly question, does UX/RT stand for *Unix Real Time*?
-Sid On Sun, Aug 1, 2021 at 5:06 PM Stefan O'Rear <[email protected]> wrote: > On Sun, Aug 1, 2021, at 3:15 AM, Gerwin Klein wrote: > > Not if you don't have any capabilities mapped into the address space. > > Correct, which would be a reasonable design for a legacy subsystem, it > > forces each syscall to raise an exception. Silly me for not pointing > > this out in the first place. > > > > I think there are some syscalls that a linux application could issue > > that would not trigger a fault: > > > > * The yield syscall takes no arguments > > * It looks to me like the non-blocking send syscalls do not raise > exceptions > > > > I can confirm that "yield" is the only syscall in seL4 that does not > > need a cap[*]. That is probably something that should be changed. > > An idea I had a long time ago (and for different reasons) was that all > system > calls should fault if the _CSpace root_ for the current thread is null. > This > allows running "foreign system" threads without changing dataflow > properties and > without touching the fastpaths at all. > > However if I understand Andrew's use case correctly this does not help > him; I > believe he is asking to run single threads containing both > microkernel-aware code > and legacy code in the same thread, with seL4 recognizing syscalls from the > address range containing microkernel-aware code, while syscalls from all > other > addresses fault. This is similar to a recently proposed Linux emulation > feature > (https://lkml.org/lkml/2020/11/18/815) and would require at least one > additional > load and test in the fastpaths. > > An alternative which would allow my understanding of Andrew's use case > would be > to consistently use the same syscall register as Linux with non-overlapping > syscall numbers. IIRC there is old seL4 or L4 documentation which implies > this > is already the case, although as detailed in several other replies it is > not. > > -s > _______________________________________________ > Devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] > _______________________________________________ Devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
