bug-hurd
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]