You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Kernel threads are not permitted to use the C library buffer I/O, "stream", interfaces. Those are interfaces like fopen, fread, fwrite, fclose, etc. Those are strictly for use by user applications. This is because these functions modify errno variables and create cancellation points and perhaps other things that are undesirable within the OS.
The thread create logic is largely the same for both kernel threads and for application threads: They both allocate a large buffer from the user memory pool for the stream FILE array. Since kernel threads this is a waste of memory since the kernel threads should not be using streams.
Remove Kernel Thread Stream Allocation
The proposal is (1) Verify that there is no use of streams within the OS, (2) remove the stream allocation for kernel threads, and (3) assure that there are proper checks in place so that there are no uses of the NULL stream array pointer.
For the most part, the OS is clean, there are essentially no use of streams within the OS. There are, however, a few violations of this that will need to be fixed; fopen() is called in some of the lc3850.
Remove the File Descriptor Array Too
A second phase would be to remove the file descriptor array from kernel threads. File descriptors are, again, only for use by applications; within the OS, file access is done using the struct file (aka, FILE), structure directly. However, I suspect that there are many hidden uses of file descriptors in the system. For one, file_open() which opens the detached file, is not fully implemented; it cheats and uses file descriptors. So let's consider removal of the file descriptor allocation as a second step after the stream allocations have been removed.
The text was updated successfully, but these errors were encountered:
No Streams in Kernel Threads
Kernel threads are not permitted to use the C library buffer I/O, "stream", interfaces. Those are interfaces like fopen, fread, fwrite, fclose, etc. Those are strictly for use by user applications. This is because these functions modify errno variables and create cancellation points and perhaps other things that are undesirable within the OS.
The thread create logic is largely the same for both kernel threads and for application threads: They both allocate a large buffer from the user memory pool for the stream
FILE
array. Since kernel threads this is a waste of memory since the kernel threads should not be using streams.Remove Kernel Thread Stream Allocation
The proposal is (1) Verify that there is no use of streams within the OS, (2) remove the stream allocation for kernel threads, and (3) assure that there are proper checks in place so that there are no uses of the NULL stream array pointer.
For the most part, the OS is clean, there are essentially no use of streams within the OS. There are, however, a few violations of this that will need to be fixed; fopen() is called in some of the lc3850.
Remove the File Descriptor Array Too
A second phase would be to remove the file descriptor array from kernel threads. File descriptors are, again, only for use by applications; within the OS, file access is done using the struct file (aka, FILE), structure directly. However, I suspect that there are many hidden uses of file descriptors in the system. For one, file_open() which opens the detached file, is not fully implemented; it cheats and uses file descriptors. So let's consider removal of the file descriptor allocation as a second step after the stream allocations have been removed.
The text was updated successfully, but these errors were encountered: