COMP 3000 2012 Week 7 Notes
- Linux source code spelunking ( see linux source cross reference)
- /documention
- /arch --> platform specific code
- /drives --> drivers for devices
- /fs -> file system stuff (ext4 is here... open.c)
do\_ prefix on something is a wrapper function that preprocesses args
- Looking at fs/ directory now...
All these help with the vfs Relationship between dentry (directory entry) and inode Contents are inodes, dentry is a string representingo
dentry, inode
Looding at struct dentry
locks --> spin lock, spinning --> locks file by constantly looping over it
- Filesystems
- blocks -> actual data
- inodes -> metadata (index done)
- directories and files are inodes
- directory inode -> name to inode mapping
- file inode -> size, last modified, pointers to data blocks, permissions, etc...
- pointers to data wihtin inodes tell you where the data is, so that you can access
it
How to explore the kernel from userspace instead of messing about in the source code.
Look at the output of $>mount
- some kernerl services are mounted to various folders (proc mounted to /proc)
in /dev/, do $> ls -l drwxr-xr-x 2 root root 700 Oct 5 22:23 block drwxr-xr-x 2 root root 120 Oct 5 22:23 bsg brw-rw---- 1 root disk 7, 7 Oct 5 22:23 loop7 crw------- 1 root root 10, 237 Oct 5 22:23 loop-control drwxr-xr-x 2 root root 80 Oct 5 22:23 mapper crw------- 1 root root 10, 227 Oct 5 22:23 mcelog crw-r--r-- 1 root root 10, 62 Oct 5 22:23 rfkill lrwxrwxrwx 1 root root 4 Oct 5 22:23 rtc -> rtc0 crw------- 1 root root 254, 0 Oct 5 22:23 rtc0 brw-rw---- 1 root disk 8, 0 Oct 5 22:23 sda brw-rw---- 1 root disk 8, 1 Oct 5 22:23 sda1 brw-rw---- 1 root disk 8, 2 Oct 5 22:23 sda2 crw-rw---- 1 root disk 21, 2 Oct 5 22:23 sg2 crw------- 1 root root 21, 3 Oct 5 22:23 sg3 lrwxrwxrwx 1 root root 8 Oct 5 22:23 shm -> /run/shm crw------- 1 root root 10, 231 Oct 5 22:23 snapshot drwxr-xr-x 3 root root 180 Oct 5 22:23 snd lrwxrwxrwx 1 root root 15 Oct 5 22:23 stderr -> /proc/self/fd/2 lrwxrwxrwx 1 root root 15 Oct 5 22:23 stdout -> /proc/self/fd/1 crw-rw-rw- 1 root tty 5, 0 Oct 17 08:47 tty crw--w---- 1 root tty 4, 0 Oct 5 22:23 tty0 crw------- 1 root root 252, 5 Oct 5 22:23 usbmon5 drwxr-xr-x 4 root root 80 Oct 5 22:23 v4l crw-rw---- 1 root tty 7, 0 Oct 5 22:23 vcs crw-rw-rw- 1 root root 1, 5 Oct 5 22:23 zero
major minor numbers? row 5, row 6 <--- LOOOK UP!
/dev is dynamically generated by udev
d = directory b = block device --> drives, etc. c = character file --> write or output sequences of characters (printers, zero, null)
random, urandom, null, zero are all device files, but they're really just special function in the kernel. They use the FILE api, you can read and write to most of them.
in /dev. run $>df .
Filesystem 1K-blocks Used Available Use% Mounted on udev 499124 8 499116 1% /dev
The file system for this is udev, dyamically generated
udev rules are set in /etc/udev, sets who can access what devices. Sets policy. see man udev what is udevd vs udev?
- udev is filesystem type and a command
- udevd is a daemon that monitors changes
If you kill udevd, your kernel will not be informed of new changes (plugged in devices). They won't be listed in /dev/. The user cannot be informed of what is actually mounted.
LOOK UP udevd
initrd has it's own /dev/ folder to allow SPECIAL devices to be mounted to before the file system and the root /dev/ is loaded
DEV IS defined in posix standard
Kernel state is defined as special files too! We don't need need special functions, just look at the files in /proc/
- all numbers are process IDs
- other devices like uptime
Ownership, groups, 'n stuff are all displayed in the files
NOTICE that all of the sizes of these files are 0.
When you call $> ps, all it's doing is calling walking the proc directory.
Proc is NOT defined in the POSIX standard. It's a linux thing.
/sys/ and /proc/ are basically the same thing, but /sys is alot more regimented, proc is loose. <---- LOOOOOOK UP!
Ex:
$> strace ifconfig You'll notice that much of what ifconfig does is reading kernel /proc/ files
NOTE: /dev/ -> devices
/proc/ and /sys/ -> KERNEL STATE
LINKS
Hardlink --> associate between name and inode. Can have many per inode.
ex: ls -l /bin | grep gunzip -rwxr-xr-x 2 root root 2251 Feb 8 2012 gunzip Two links to gunzip's inode. Meaning, uncompress points to the same inode gunzip and uncompress binaries have the same inode
Symlink: pointer to a name, not an inode. You can have pointer to a name that's a has a hardlink to an actual piece of data