Erm...
I didn't read the whole text thoroughly, but it seems you're suggesting stdin and stdout being somewhat special, like, stdin always coming from the keyboard, and stdout always going to the screen.
If that observation is correct, you got it
completely wrong.
stdin and stdout (and stderr...) are defined, by the C language standard, to be
streams. From a userspace C application's view, there is
no difference, technically, between:
Code:
printf( "foo" );
and
Code:
fprintf( stdout, "foo" );
and
Code:
FILE * fh = fopen( "foo.txt", "w" );
fprintf( fh, "foo" );
When a user process starts, the kernel sets up three streams for the process, and (on POSIX) lists them as file descriptors 0 (stdin), 1 (stdout), and 2 (stderr) respectively.
That's why you see bash lines like:
Code:
./xyz > log.txt 2> err.txt
These streams are
by no means limited to keyboard and / or screen, it's just their default
on most machines. (It isn't on embedded systems, for example.) If you start a process like this:
Code:
./xyz > out.txt < in.txt
both stdin and stdout are actually files. What's more, a userspace application could use freopen() to "close" stdout / stdin and reattach them to completely different files from what you wrote on the command line.
What an OS
has to implement is some way for keyboard input to be available to read(2) from, and some way to write(2) to screen.
Unix/POSIX, with its "everything is a file" philosophy, does the trick by providing e.g. the terminal as a file (/dev/pts/1).
The difference between stdout and stderr, by the way, is that stdout is buffered, stderr is not.
And before you go ahead and implement generic stream buffering on the kernel side, be advised that this buffering is already being done by the C library in userspace. The kernel itself shouldn't buffer individual streams. Perhaps it should buffer writes to a device, but not on the individual stream level.
Perhaps I'll join your efforts with this page later, but right now those remarks above must suffice.