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
