fgets(buf, sizeof(buf), stdin) never returns.

Implement thread yield without sleeping till next tick.

If the working directory of a process is removed the process is jailed to that directory
as the vnode doesn't get freed but dot and dotdot links are deleted. For some reason
chdir to / is not working either so rmdir . effectively creates a chroot-like jail.

Doesn't show up in stat()

first disable interrupts and then lock, should work with MP.

getcwd should try to construct the full path by going up to the root by following .. links and finding out the name of the previous directory. Full path should not contain any '.', '..', or extra '/' special characters, though those characters can appear in a directory name.

• Try to boot and mount fatfs
• Implement whatever is needed to get it bootable

Init message of a init function is now printed before printing init messages of the dependencies of the original init function i.e. before it's actually executed giving wrong impression of booting state.

Figure out if it's forking that's slow or reading the file system.

umount() presumably works ok for ramfs but it doesn't check if there is any references to the vnodes like it should do before removing them.

Some fatfs file operations like mkdir, rmdir and unlink seems to always return -EIO even if operation was successful.

# ls
0 40755 0:0 .
0 40755 0:0 .. 
1 40755 0:0 dev

# mkdir dir
# touch file
# ls
0 40755 0:0 .
0 40755 0:0 ..
1 40755 0:0 dev
3 100644 0:0 file
2 40750 0:0 dir

# unlink file
# ls
0 40755 0:0 .
0 40755 0:0 ..
1 40755 0:0 dev

dir is not removed after this operation but it doesn't show up in ls anymore.

fstat() seems to always return something like: 4, -1610612733 no matter which file is stat'd.

Wide char and locale support is practically missing from libc.

stdio.h
locale.h
wchar.h

Consider a process with two threads, both obviously have a stack that is accessible by threads of that process. Now if thread a has made a syscall but go interrupted and thread b is put on execution. What happens is that thread b could possibly read stacked kernel data from the stack of thread a.

To prevent this we'd need separated kernel mode stack for each thread. There is a little stub implemented but commented out in sched.c. Only "problem" is that it greatly complicates entry code to the scheduler. Another option might be hide/copy the data out before switching context but it doesn't sound like a feasible idea.

As sched is now built to push registers into a user stack on task switch it means that user can easily cause scheduler to panic due to write protection of the code section.

sched_current_thread_yield(SCHED_YIELD_IMMEDIATE) seems to cause memory corruption in scheduler and thus kernel panics and hangs.

• proper buffering
• modes
• controlling terminal
• pty creation and destruction

Would be lot simpler if we'd have only a single struct type to define a new thread instead of two that are both required in kernel space as well as when making a syscall.

If Parent thread calls thread_terminate() and if execution is then transferred to the scheduler it may may call the same function again and proper timing may break the scheduler.

readdir adds one extra ref per call for cwd (.).

It would be useful to have a (possibly statically compiled) interface to add periodically executed handlers to calculate for example loadavg or some other stats. This could be either built in timers or scheduler. Naturally these periodic tasks should be very small since scheduler is not pre-emptible.

It can be also considered if we should create a kernel thread that would handle most of these periodic tasks. Some tasks may have more strict deadlines so this kind of thread based interface may not suit for those tasks?

Let act_maxproc = 10.

If a process with pid = 10 is created it will break the procfs so that /proc/10 dir remains in the file systems but is unusable. This isn't necessarily related to procfs at all but handling of maxproc limit itself.

cat file.txt actually seems to do cat file.txt "some invalid string" and thus fails every time.

There seems to be some strange cases where thread stack is unavailable for a short
period of time.

Init v0.0.1
4:src/proc.c:374: proc_dab_handler(): MOO
0:src/hal/arm11/arm11_mmu.c:618: SEGFAULT @ 0x00013f3c
0:src/hal/arm11/arm11_mmu.c:673: Oops, Kernel panic
0:src/hal/arm11/arm11_mmu.c:673: Can't handle data abort
pc : 0x00013f3c
fsr : 0x0000000d (Section permission fault)
far : 0x00402ef4
proc info:
pid : 0x00000001
tid : 0x00000001

If sd card or driver is in read-only mode but fatfs is mounted rw the fs driver will fail if a file is created. This doesn't however cause creat to fail but instead read and write operation after a file creation will fail.

If "ls" is executed on fatfs chrooted shell the refcount for the cwd is incremented twice per lookup.
This doesn't seem to happen if "ls" is executed on non-cwd.

The issue might be related to namei or lookup fn in fatfs.

Should be implemented.

functions declared in stdio.h stdlib.h are missing float support.

Move umount function pointer to superblock struct to make it callable for inherited file systems.

fs pointer in sb struct can't be altered thus we need to move umount func pointer to sb struct as
a workaround. The solution is kind of suboptimal but it requires least effort for now.

Large data structures like task_table should be allocated dynamically either with kmalloc or maybe preferably with dynmem since we may want to make these quite big for any real use.

Implement a new scheduler interface that allows hooking multiple schedulers to the kernel at the same time and preferably even at run time.

Global variables for current task can't be used on MP system:
extern volatile pid_t current_process_id;
extern volatile proc_info_t * curproc;
extern volatile threadInfo_t * current_thread;

These should be possibly replaced with arrays which specify current value for each core.

If CDS is compiled the kernel will fail after boot due to incorrect/corrupted kstack struct.

Creating and removing directories breaks the fs. This is a bug in inode array allocation.

Sometimes images generated by mkrootfs are somehow invalid and Zeke can't execute tests under /opt/test/libc.

umount / should return fail with an error code instead of breaking the system.

# debug thread create
# debug proc fork

=> DAB handling failed: -2

pc  : 0x100024e0
fsr : 0x0000080f (Page permission fault)
far : 0x10002428
proc info:
pid : 9
tid : 7

PID of a new process seems to improperly bound to maxproc quite soon after some fork()s. PID reset might be invalid for small PID sets?

If getdents() is called with any invalid fildes it crashes the process or sometimes crashes the kernel by branching to addr 0.

Findings:

• file that isn't a dir causes the process to hang
• negative fildes causes branch to 0, probably non-existing function pointer 0->vnode->vnode_ops->...

Steps to reproduce:
# tish
...
# echo a b c
a b c
# echo d e f
d e f
# exit
status: 0
#0:sched_tiny/heap.c:110: Oops, Kernel panic
0:sched_tiny/heap.c:110: sched heap out of bounds

Enabling LFN doesn't change file name representation in VFS.

Mount fails to mount on top of root (/) and returns ENOENT. This seems to happen at least with devfs and fatfs.

msleeps of few millisecs seems to cause a thread to stay in sleep forever.

Instead of having wait_tim we should have a function to delete all associated timers provided by timers.