Diary 2016/12/12- [DRAFT]
Created at 2016-12-24T02:18:21.000Z
  • Kernel interrupt/exception handling

    • what x86 does (see "Hardware Handling of Interrupts and Exceptions")
      • hardware changes:
        • instruction pointer (cs and eip loaded from IDT)
        • stack pointer (ss and esp loaded from TSS. this doesn't happen if cpu is already in kernel mode ?)

    • is x86 thread_info only unsigned long? (where is precious preempt_count ?)
      • see preempt.h
    • other x86 things
      • arch/x86/include/asm/irq_vectors.h
      • arch/x86/include/asm/segment.h
    • summerize again terminology
      • preempt (kernel)
        • non voluntarily process switch during kernel mode
        • see section "kernel preemption)
        • process preemption in scheduling lingo
          • one process preempts other process
      • reentrant (code)
        • run code (function) in a nested way on the same cpu
        • e.g. interrupt handling
      • concurrent (data)
        • run same code or access same data from multiple cpus
    • type of things
      • exception
        • started from user mode instruction (except page fault)
        • exception handling don't (mostly) nest each other as long as we assume kernel is bug free. syscall can induce page fault, so thery can nest.
        • interrupt handling could start when cpu is exception-handling kernel control path.
        • context switch can happen for page fault handler.
      • interrupt
        • interrupt handling could nest each other
        • exception handling (including page faults) won't start here as long as we assume kernel is bug free
        • context switch won't happen, or I/O device interrupt doesn't refer to data specific to the current process.
        • but, when return from interrupt (e.g. schedular_tick), process can switch.
      • (fast) system call
    • anyway, page fault exception handling is so special.
    • bottom half scheduling
      • softirq (tasklet)
      • workqueue
    • still confusing terms
      • (A)PIC ((advanced) programmable interrupt controller)
      • PCI (peripheral component interconnect)
      • ACPI (advanced configuration and power interface)
  • Kernel timer interrupt for process scheduling

    • two types: per-cpu one (apic) and global one
    • per-cpu one is crutial for process scheduling
    • x86/kernel/apic/apic.c
      • kernel_init_freeable -> smp_prepare_cpus (x86/include/asm/smp.h) -> smp_ops.smp_prepare_cpus (smp.c) -> smp_prepare_cpus () -> native_smp_prepare_cpus -> apic_bsp_setup -> x86_init.timers.setup_percpu_clockev -> setup_APIC_timer -> clockevents_register_device -> ... -> dev->event_handler = tick_handle_periodic

  • Kernel module

    • build system
      • macros: CONFIG_MODULES MODULE

    • user land interface
      • module dependency is resolved on user land by modprobe
      • single module loading by init_module, finit_module
      • see busybox/modutils
    • dependency
      • modules.dep, System.map
      • how do you describe it in kernel module source? (some KBuild thing or some macro?)
        • you don't have to describe. depmod does it automatically by checking exported symbols.
    • ? initialization (code, data, data/function symbol resolution)
      • how do you know kernel's existing symbol's address (kernel text and data) ?
      • see apply_relocate_add (in arch/x86/kernel/module.c)
    • understand elf format
      • especially, external symbol representation (variable reference, function call)
      • read include/uapi/linux/elf.h
  • ? Kernel I/O scheduling

  • ? Nginx reading

    • follow the basic code path:
      • socket -> listen -> poll -> accept -> read(recv) -> write(send)

  • ? Clang/LLVM casual walkthrough

    • clang optimization
    • llvm optimization

  • ? device hotplug with udev/uevent

  • Kernel logging facility

    • /proc/kmsg, /dev/kmsg, syslog(2)
      • /dev/kmsg is one of devlist[] in linux/drivers/char/mem.c

    • tools: dmesg, systemd-journald, rsyslog (/var/log/kern.log)
    • read linux/kernel/printk/printk.c, fs/proc/kmsg.c
    • read busybox/util-linux/dmesg.c
  • Kernel tty

    • User space:
    • systemd (pid1) (see http://0pointer.de/blog/projects/serial-console.html)¨B¨K42K¨B
    • busybox/loginutils/getty.c
      • setsid (see setsid(2))
      • open tty (specified as an argument) as stdin/stdout/stderr
      • ioctl(TIOCSCTTY) (see tty_ioctl(4))
      • setup tty attributes
      • execve to login process

    • busybox/loginutils/login.c
      • no tty work here
      • call pam library and vfork-exec shell process if authenticated
      • what happens after shell exits depends on pid1. (for this case, since getty@.service has Restart=always, it goes back to getty.)
    • ? how tmux handles pseudo ttys
    • ? ssh client/server
    • GUI terminal emulator (e.g. xterm)
      • pts(4) and simulate tty with GUI input/output.
    • Kernel things:
    • Kconfig:
      • TTY (tty subsystem)
      • VT (virtual terminal (Ctrl-Alt-F1 things))
      • VT_CONSOLE (system console for single user mode)
    • how many kinds of device files out there ? (device number and initialization step)
      • tty_init
        • 5:0 - /dev/tty
        • 5:1 - /dev/console
      • vty_init
        • 4:0 - /dev/tty0
      • tty_register_driver(console_driver)
        • 4:1...63 - /dev/tty1...63
      • vty_init -> vcs_init
        • 7:0 - /dev/vcs
        • 7:1 - /dev/vcs1
        • 7:128 - /dev/vcsa
        • 7:129 - /dev/vcsa1
      • con_init
        • ? I think this is not something used for use space, so let's skip it?
      • /dev/ttyS0...31
    • kernel parameters: console
    • keymap (dumpkeys, loadkeys) is a kernel thing
    • initialization steps
      • start_kernel -> console_init -> (console_initcall) -> con_init
      • start_kernel -> rest_init -> kernel_thread(kernel_init, ...) -> kernel_init -> kernel_init_freeable -> do_basic_setup -> do_initcalls -> (fs_initcall) -> chr_dev_init -> tty_init -> vty_init
    • let's forget about VT_CONSOLE for now. Understand how virtual console works.
    • eary things
      • register_console (printk.c)
    • serial, tty, console, display server (Xorg)
    • does Xorg needs to know about virtual console ? (I mean, does it know about fg_console or change_console things ?)
    • vt switching (there're many entrypoint which you can find by grepping set_console)
      • ioctl (e.g. VT_ACTIVATE) -> set_console -> console_callback (vt.c) -> change_console (vt_ioctl.c) -> ... -> redraw_screen, wake_up_interruptible(&vt_event_waitqueue);
      • ? does "ctrl-alt-F1" corresponds to k_cons which is *(k_handler[5])(...)
    • drivers/vt/keyboard.c
      • initialization: kbd_init -> input_register_handler(&kbd_handler) -> kbd_connect -> ...
      • event handling: kbd_event -> kbd_keycode -> tty_insert_flip_char, atomic_notifier_call_chain(&keyboard_notifier_list, ...)
      • process read operation:
        • tty_read => tty->ldisc->ops->read (which is n_tty_read) => copy_from_read_buf
        • ? how tty->disc_data (n_tty_data) and tty->port->buf relate each other
      • ? how do you deal with hot-plugged keyboard (since it looks like kbd_init is only called at kernel initialization step) ?
    • drivers/vt/vc_screen.c
      • process write operation:
        • tty_write =>
      • ? how to hook with display driver ? (including monitor choice things)
        • who displays "vc_data" physically ?
    • ? how tty_operations and file_operations relate each other ?
      • struct cdev => file_operations
      • struct tty_struct, tty_driver => tty_operations
      • tty_driver => tty_struct
      • tty_driver => cdev, device
      • tty_register_driver => ... => driver->cdevs[index]->ops = &tty_fops
  • Kernel input subsystem

    • ? Documentation/driver-model
    • example
      • drivers/input/keyboard/serio.h, drivers/input/serio/i8042.c
        • struct bus_type serio_bus
        • struct platform_driver i8042_driver
        • ? how irq handler is registered ?
        • ? jesus crist, there's no input_dev. I'm looking at wrong driver now ?
        • ? what's the relavancy with classic x86 IRQ 1 keyboard interrupt ?

    • /proc/bus/input/{handlers, devices}
    • struct input_handler, struct input_dev
    • input_dev_list, input_handler_list
    • how/when input subsystem probes bus/device/driver ?
      • input_handler includes bool (*match)(struct input_handler *handler, struct input_dev *dev)
    • ? how display server (or whatever user space process) interfere with keyboard input ?
      • create some kernel module and register something with keyboard_notifier_list ?
        • no way ?
    • ? why can mknod be done from kernel module always?
    • ? who mkdnod /dev/tty things ?
    • ? what is udev filesystem for /dev (where is an implementation ? is this from systemd ?)
  • ? Kernel display (output) subsystem

    • frame buffer

  • Computer Graphics in the wild

    • ? GPU architecture, OpenGL architecture

  • ? Kernel boot up in detail

    • x86, EFI, grub, setup_64.S, start_kernel, swapper process, pid 1

  • GNU Make

  • ssh and tmux

    • setup: install tmux on remote host
    • workflow:
      • run ssh <remote host>
      • run tmux (it starts tmux process and attaches current console from sshd's shell to tmux's initial shell)
      • ... do things on shells under tmux ...
      • detach console from tmux's shell by C-b d (you can detach even when running a process under tmux's shell)
      • exit from ssh
      • run ssh <remote host> and attach to existing shell by tmux attach

    • internal
      • tmux process runs under init instead of sshd
      • shell processes are children of tmux process
      • ? know more about console and child process handling
  • Android

    • build system: https://source.android.com/source/building.html¨B¨K83K¨B
    • basics:
      • root file system hierarchy
        • see out/target/product/generic/{root, system, data, cache}

      • kernel:
        • external/qemu/docs/ANDROID-KERNEL.TXT
        • prebuilds/qemu-kernel/build-kernel.sh
        • are these version 3.18?
      • hardware emulation (qemu)
        • external/qemu
        • prebuilds/android-emulator
    • ? basics walkthrough
      • ? kernel boot
      • ? init system (PID 1)
      • ? device initialization
      • ? desktop environment
      • ? process lifecycle with ART
      • ? interface between device and process (syscall? JNI?)
  • Build Chromium