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
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 -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems