Ok I see your problem.
vfs maintains file descriptor table for every process in the system.
At every index it stores information of descriptor type and device it
points to. The indexes 0,1,2 have special meaning in the context of
process. 0 indicates std input, 1 indicates std output and 2 indicates
std err.
So whenever you use open(), socket(), or any other system call which
returns descriptor (expect fopen .. libc functions) is returning the
index in to this table where the info about device or operation is
stored. So, whenever you use that descriptor number with other sys
calls it will map in to index and extracts the information.
normal calls like printf, cout uses "stdin, stdout, stderr" for printing out.
> We all know that when an application writes to stdout, data ends up in
> the console.
Because for that process index 1 maps to /dev/stdout
> Okey so if I m on my development board and if I run an app, all the
> prints comes to the console (eg /dev/ttyS0).
same as above
> If I m on any server using ssh and all apps prints comes on my putty
> (eg through /dev/pts/176).
its ssh implementation. It uses pty as stdout for printing.
In such case initializing stdout = fdopen on open("/dev/stdout", "")
descriptor will do your job.
or use dup to set index 1 to given fd in that process
--Sri.
On Mon, Apr 23, 2012 at 6:15 AM, Arun KS <getarunks@xxxxxxxxx> wrote:
> Hello Guys,
>
> We all know that when an application writes to stdout, data ends up in
> the console.
>
> Okey so if I m on my development board and if I run an app, all the
> prints comes to the console (eg /dev/ttyS0).
> If I m on any server using ssh and all apps prints comes on my putty
> (eg through /dev/pts/176).
>
> Where is the code which maps fd 1 to the console in kernel?
> If you guys have any pointers, please share.
>
> While opening a device (for eg /dev/something), the vfs calls that
> drivers, whose major and minor number matches.
> But in case of stdout, how vfs resolves the write to the fd 1 and send
> it to the corresponding console driver?
>
> Thanks,
> Arun
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@xxxxxxxxxxxxxxxxx
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
--
Regards,
Sri.
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
