utcb as a shared page instead of the message registers.
Implemented the code that passes task information from mm0 to fs0
using the fs0 utcb. The code seems to work OK but:
There's an issue with anon pages that they end up on the same swapfile
and with same file offsets (e.g. utcb and stack at offset 0). Need to
fix this issue but otherwise this implementation seems to work.
TODO:
- Separate anon regions into separate vmfiles.
- Possibly map the stacks from virtual files so that they can be
read from userspace in the future for debugging.
- Possibly utcb could be created as a shared memory object using shmget/shmat
during startup.
Environment is backed by a special per-task file maintained by mm0 for each task.
This file is filled in by the env pager, by simple copying of env data into the
faulty page upon a fault. UTCB and all anon regions (stack) could use the same
scheme.
Fixed IS_ERR(x) to accept negative values that are above -1000 for errors. This
protects against false positives for pointers such as 0xE0000000.
modified: include/l4/generic/scheduler.h
modified: include/l4/macros.h
modified: src/arch/arm/exception.c
modified: tasks/fs0/include/linker.lds
modified: tasks/libl4/src/init.c
modified: tasks/libposix/shm.c
new file: tasks/mm0/include/env.h
modified: tasks/mm0/include/file.h
new file: tasks/mm0/include/lib/addr.h
deleted: tasks/mm0/include/lib/vaddr.h
modified: tasks/mm0/include/task.h
new file: tasks/mm0/include/utcb.h
new file: tasks/mm0/src/env.c
modified: tasks/mm0/src/fault.c
modified: tasks/mm0/src/file.c
modified: tasks/mm0/src/init.c
new file: tasks/mm0/src/lib/addr.c
modified: tasks/mm0/src/lib/idpool.c
deleted: tasks/mm0/src/lib/vaddr.c
modified: tasks/mm0/src/mmap.c
modified: tasks/mm0/src/shm.c
modified: tasks/mm0/src/task.c
new file: tasks/mm0/src/utcb.c
modified: tasks/test0/include/linker.lds
This will help when syscalls have long arguments individual
utcbs can be mapped to server tasks and kept mapped in until the
tasks die, as opposed to map requests every time a server task maps
a different utcb at the same virtual address.
The changes have preparation code to also passing the utcb info
through the stack as part of the environment.
To sum up env and arg regions have also been added above the stack and
env region is to be used to pass on the utcb address information at
task startup.
Added reading pages from the page cache into user buffer for sys_read.
Increases stack sizes to 4 pages.
Updated README to include more details about multi-pager environments.
This implements the infrastructure for read/write system calls where
file content is first searched in mm0's page cache and then read-in
or written via the vfs read/write functions.
modified: tasks/fs0/src/syscalls.c
modified: tasks/mm0/include/lib/bit.h
modified: tasks/mm0/include/lib/idpool.h
modified: tasks/mm0/include/task.h
modified: tasks/mm0/include/vm_area.h
modified: tasks/mm0/main.c
modified: tasks/mm0/src/devzero.c
modified: tasks/mm0/src/fault.c
new file: tasks/mm0/src/file.c
modified: tasks/mm0/src/init.c
modified: tasks/mm0/src/lib/bit.c
modified: tasks/mm0/src/lib/idpool.c
modified: tasks/mm0/src/task.c
We now have a single dirbuf of size PAGE_SIZE kept on the vnode. This is
to be used for directory contents only. The reason it's kept on FS0 is
because the contents are modified by calls such as mkdir or create, and otherwise
these would have been handled by mm0 on the page cache buffers, which wouldn't work.
Need to still decide whether content buffers are provided by mm0,
whether need to return them back to mm0, and the read count.
modified: tasks/fs0/src/memfs/vnode.c
modified: tasks/fs0/src/syscalls.c
Headers 3 headers related to message registers and utcbs are now merged under
utcb.h in libl4. Some message register definitions used by the kernel are now
moved into kernel's glue/message.h. This avoids the duplication of same
definitions. Also the total number of mregs are now determined by arch-specific
kernel header, which is good.
Modified ipc handling so that from now on the kernel inspects and sets
the sender id if the receiver is receiving from L4_ANYTHREAD. This posed
a security problem since the receiver could not trust the sender for
sender information.
