[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
I/O Path
From: |
Samuel Thibault |
Subject: |
I/O Path |
Date: |
Thu, 27 Mar 2008 16:02:54 +0100 |
User-agent: |
Mutt/1.5.12-2006-07-14 |
Nirmal Thacker, le Thu 27 Mar 2008 00:27:52 -0400, a écrit :
> Could you point me to the path in the code directory structure?
It's all spread across a lot of code. You may want to follow the path of
IOs from libc's read() to kernel drivers:
- Glibc's Hurd read() is in glibc/sysdeps/mach/hurd/read.c:__libc_read()
- that calls glibc/hurd/fd-read.c:_hurd_fd_read()
- that calls __io_read, which is an RPC, i.e. that actually results into
the ext2fs server calling hurd/libdiskfs/io-read.c:diskfs_S_io_read()
- that calls _diskfs_rdwr_internal, which calls
hurd/libpager/pager-memcpy.c:pager_memcpy(), which usually basically
just tell the kernel to virtually project the memory object
corresponding to the file in the caller process's memory. No read is
actually done.
- Then, when the process actually reads the data, the kernel gets the
user page fault (gnumach/i386/i386/trap.c:user_trap()), which calls
vm_fault(), etc. until actually getting to
gnumach/vm/vm_fault/vm_fault_page() which eventually calls
memory_object_data_request(), which is an RPC, i.e. that actually
results into the ext2fs server calling
hurd/libpager/data-request.c:_pager_seqnos_memory_object_data_request()
- that calls hurd/ext2fs/pager.c:pager_read_page(), which looks for
where the data is on the disk, and eventually calls
hurd/libstore/rdwr.c:store_read, which eventually calls device_read(),
which is an RPC, i.e. that actually gets into the kernel calling
gnumach/linux/dev/glue/block.c:device_read(). From there there is no
RPC involved any more so you should be able to find your way yourself.
Note: RPCs are defined in .defs files.
Samuel
- I/O Path,
Samuel Thibault <=