* stdout to console [not found] <CABOM9Zq_8+c+RV_kunwbvgFp0454-s4eAd_HQTCRQpR9ZbmZyg@mail.gmail.com> @ 2012-04-23 10:15 ` Arun KS 2012-04-23 12:09 ` Jonathan Neuschäfer 2012-04-25 18:09 ` Sri Ram Vemulpali 0 siblings, 2 replies; 6+ messages in thread From: Arun KS @ 2012-04-23 10:15 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* stdout to console 2012-04-23 10:15 ` stdout to console Arun KS @ 2012-04-23 12:09 ` Jonathan Neuschäfer 2012-04-25 18:09 ` Sri Ram Vemulpali 1 sibling, 0 replies; 6+ messages in thread From: Jonathan Neuschäfer @ 2012-04-23 12:09 UTC (permalink / raw) To: kernelnewbies On Mon, Apr 23, 2012 at 03:45:00PM +0530, Arun KS 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 It's in init/main.c, around line 823. "strace" is a useful tool for trying to figure out what exactly a user space process does. The man pages of various system calls (open, fork, exec, dup, etc.) may also provide valuable information. Thanks, Jonathan Neusch?fer ^ permalink raw reply [flat|nested] 6+ messages in thread
* stdout to console 2012-04-23 10:15 ` stdout to console Arun KS 2012-04-23 12:09 ` Jonathan Neuschäfer @ 2012-04-25 18:09 ` Sri Ram Vemulpali 2012-04-25 18:59 ` Jonathan Neuschäfer 2012-04-26 3:56 ` Arun KS 1 sibling, 2 replies; 6+ messages in thread From: Sri Ram Vemulpali @ 2012-04-25 18:09 UTC (permalink / raw) To: kernelnewbies 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@gmail.com> 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 at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- Regards, Sri. ^ permalink raw reply [flat|nested] 6+ messages in thread
* stdout to console 2012-04-25 18:09 ` Sri Ram Vemulpali @ 2012-04-25 18:59 ` Jonathan Neuschäfer 2012-04-26 3:56 ` Arun KS 1 sibling, 0 replies; 6+ messages in thread From: Jonathan Neuschäfer @ 2012-04-25 18:59 UTC (permalink / raw) To: kernelnewbies On Wed, Apr 25, 2012 at 02:09:24PM -0400, Sri Ram Vemulpali wrote: > > 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 Or rather, /dev/stdout maps to fd 1. $ ls -l /dev/stdout lrwxrwxrwx 1 root root 15 Apr 25 18:18 /dev/stdout -> /proc/self/fd/1 Thanks, Jonathan Neusch?fer ^ permalink raw reply [flat|nested] 6+ messages in thread
* stdout to console 2012-04-25 18:09 ` Sri Ram Vemulpali 2012-04-25 18:59 ` Jonathan Neuschäfer @ 2012-04-26 3:56 ` Arun KS 2012-04-27 5:46 ` Sri Ram Vemulpali 1 sibling, 1 reply; 6+ messages in thread From: Arun KS @ 2012-04-26 3:56 UTC (permalink / raw) To: kernelnewbies Thanks Sri Ram and Jonathan, On Wed, Apr 25, 2012 at 11:39 PM, Sri Ram Vemulpali <sri.ram.gmu06@gmail.com> wrote: > 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. Okey > 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 Hmm... Will sshd open /dev/stdout? I think it uses /dev/ptmx and /dev/pts/* device files. Plz have a look here, http://linux.die.net/man/4/pts Arun > > > --Sri. > > On Mon, Apr 23, 2012 at 6:15 AM, Arun KS <getarunks@gmail.com> 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 at kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > > > -- > Regards, > Sri. ^ permalink raw reply [flat|nested] 6+ messages in thread
* stdout to console 2012-04-26 3:56 ` Arun KS @ 2012-04-27 5:46 ` Sri Ram Vemulpali 0 siblings, 0 replies; 6+ messages in thread From: Sri Ram Vemulpali @ 2012-04-27 5:46 UTC (permalink / raw) To: kernelnewbies Dude, It is more of implementation dependent. Where you want your output to display. pty is a method of sending data between two end points of communications but acts with concept of master and slave. It is written on tty driver. In case of ssh it is implementation dependent. I will leave it to you to understand the concept of vfs. Initially it is confusing, but there is lot of material online. You url is a good start. All the best. Sri. On Wed, Apr 25, 2012 at 11:56 PM, Arun KS <getarunks@gmail.com> wrote: > Thanks Sri Ram and Jonathan, > > On Wed, Apr 25, 2012 at 11:39 PM, Sri Ram Vemulpali > <sri.ram.gmu06@gmail.com> wrote: >> 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. > Okey >> 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 > > Hmm... Will sshd open /dev/stdout? > > I think it uses /dev/ptmx and /dev/pts/* device files. > > Plz have a look here, > http://linux.die.net/man/4/pts > > Arun > >> >> >> --Sri. >> >> On Mon, Apr 23, 2012 at 6:15 AM, Arun KS <getarunks@gmail.com> 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 at kernelnewbies.org >>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> >> >> >> -- >> Regards, >> Sri. -- Regards, Sri. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-04-27 5:46 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CABOM9Zq_8+c+RV_kunwbvgFp0454-s4eAd_HQTCRQpR9ZbmZyg@mail.gmail.com>
2012-04-23 10:15 ` stdout to console Arun KS
2012-04-23 12:09 ` Jonathan Neuschäfer
2012-04-25 18:09 ` Sri Ram Vemulpali
2012-04-25 18:59 ` Jonathan Neuschäfer
2012-04-26 3:56 ` Arun KS
2012-04-27 5:46 ` Sri Ram Vemulpali
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.