Thanks for giving the pointers.
I tried with the strace for below program, what does mmap2 do below?.
Can i assume that read is a syscall made for getchar?. Also at what
point it geoes into kernel space?. I would like to have some
understanding on this.
execve("./a.out", ["./a.out"], [/* 15 vars */]) = 0
brk(0) = 0x85d0000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7896000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=128666, ...}) = 0
mmap2(NULL, 128666, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7876000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320h\1\0004\0\0\0\344"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1442180, ...}) = 0
mmap2(NULL, 1451632, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE,
3, 0) = 0xb7713000
mprotect(0xb786f000, 4096, PROT_NONE) = 0
mmap2(0xb7870000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15c) = 0xb7870000
mmap2(0xb7873000, 9840, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7873000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7712000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb77126c0,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
limit_in_pages:1, seg_not_present:0, useable:1}) = 0
open("/dev/urandom", O_RDONLY) = 3
read(3, "L\350\325"..., 3) = 3
close(3) = 0
mprotect(0xb7870000, 8192, PROT_READ) = 0
mprotect(0x8049000, 4096, PROT_READ) = 0
mprotect(0xb78b5000, 4096, PROT_READ) = 0
munmap(0xb7876000, 128666) = 0
fstat64(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 5), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7895000
read(0, 1 <- Here i gave an input 1
"1\n"..., 1024) = 2
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 5), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7894000
write(1, " You Entered: 1\n"..., 16 You Entered: 1
) = 16
exit_group(16) = ?
On Tue, Jun 29, 2010 at 11:04 AM, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote:
> The interface between userspace and kernel is very clear, because
> userspace code will never be executed in kernel and vice versa.
> Userspace interface with kernelspace via system call, cat
> /proc/kallsyms | grep " sys_" and u can see MOST the system FROM THE
> KERNEL side. Minus the sys_ and u can search the web for the
> corresponding userspace function API - most of the time. (Cannot
> generalize too far, because I have never seen many of these symbols in
> userspace or even in kernel myself :-)).
>
> From below:
>
> #include <stdio.h>
>
> main()
> {
> char c=getchar();
> printf("%c\n", c);
> }
>
> Doing a "strace" we can see that read() is one key API used for I/O -
> its kernel API is sys_read().
>
> Three option are available (minus kdb and lttng): systemtap or ftrace
> or kgdb + VirtualBox, as sys_read() is used for many reasons - many
> paths are will reach sys_read().
>
> Eg, for ftrace:
>
> you will get 22K lines of traces then zooming down into sys_read:
>
> 17423 getchar-6557 [000] 157.098641: kmem_cache_free <-putname
> 17424 getchar-6557 [000] 157.098642: sys_read <-syscall_call
> 17425 getchar-6557 [000] 157.098643: fget_light <-sys_read
> 17426 getchar-6557 [000] 157.098643: vfs_read <-sys_read
> 17427 getchar-6557 [000] 157.098644: rw_verify_area <-vfs_read
> 17428 getchar-6557 [000] 157.098644:
> security_file_permission <-rw_verify_area
> 17429 getchar-6557 [000] 157.098645: cap_file_permission
> <-security_file_permission
> 17430 getchar-6557 [000] 157.098645: do_sync_read <-vfs_read
> 17431 getchar-6557 [000] 157.098646:
> generic_file_aio_read <-do_sync_read
>
> There is almost NO mapping to any keyboard at all......
>
> Then I used systemtap:
>
> ====>evdev_event
> 0xc047fb20 : evdev_event+0x0/0x90 [kernel]
> 0xc0479d92 : input_pass_event+0xb2/0xc0 [kernel]
> 0xc047c3c2 : input_handle_event+0x82/0x440 [kernel]
> 0xc047c878 : input_event+0x68/0x80 [kernel]
> 0xc0481d35 : atkbd_interrupt+0x645/0x6a0 [kernel]
> 0xc0476f7d : serio_interrupt+0x3d/0x90 [kernel]
> 0xc04782a1 : i8042_interrupt+0x1d1/0x330 [kernel]
> 0xc01ad970 : handle_IRQ_event+0x60/0x140 [kernel]
> 0xc01af9a1 : handle_edge_irq+0xb1/0x140 [kernel]
> 0xc0104bdf : handle_irq+0x1f/0x30 [kernel]
> 0xc05ceedb : do_IRQ+0x4b/0xc0 [kernel]
> 0xc0103469 : common_interrupt+0x29/0x30 [kernel]
> 0xc017007b : alloc_pid+0x19b/0x360 [kernel] (inexact)
> 0xc03a2cc4 : acpi_idle_enter_bm+0x262/0x291 [kernel] (inexact)
> 0xc04b717d : cpuidle_idle_call+0x8d/0x110 [kernel] (inexact)
> 0xc0101e9a : cpu_idle+0x5a/0x90 [kernel] (inexact)
> 0xc05c24ba : start_secondary+0x176/0x1ec [kernel] (inexact)
>
> Almost got to the key APIs. But the systemtap tracing above is
> assited by source code reading: drivers/input/keyboard/*.c (among
> the different keyboard, the commonly used AT/PS2 is atkbd.c) and also
> drivers/char/tty_io.c (looking through all the "read" function ptrs in
> the fops structure within this file). The latter is the path taken
> when the keyboard input comes from remote login terminal).
>
> Searching through the source (for "keyboard") indicate many other
> places which can directly access the keyboard via port I/O API
> (inp_b()) as well.
>
> Well I could be wrong.....as someone always seemed to be able to
> suggest some ideas which proved me wrong....any comments?
>
> On Tue, Jun 29, 2010 at 10:31 AM, Rahul Kumar <mailforgroup@xxxxxxxxx> wrote:
>> Hi,
>>
>> What will happen when getchar () (or some other operation) is called
>> from userspace.
>> I would like to know all the trace until you receive the character
>> from kernel to userspace.
>>
>> My rough understanding is:
>> getchar calls library function which calls system call...etc.
>> I need some proper explanation. Can any one clarify me on this. Thanks.
>>
>> --
>> To unsubscribe from this list: send an email with
>> "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
>> Please read the FAQ at http://kernelnewbies.org/FAQ
>>
>>
>
>
>
> --
> Regards,
> Peter Teoh
>
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
