2019操作系统课程设计:可加载模块和动态链接库

在本页面维护操作系统课程设计大实验"可加载模块和动态链接库"的相关信息。老师、助教和选做课程设计的同学可修改该页面的内容。

课程设计目标:

  1. Loadable Kernel Module support.
    • Dependency:
      • Partially done! vmalloc: Kernel Virtual Memory (kseg2)

        • Why?
          • Now we only have kmalloc(LockedHeap)

          • Not flexible in page permission & page allocation(32MiB is not enough)

        • Use a 512 GiB item as virtual space
        • Virtual space management: same as contiguous memory management
          • Load position independent module into some location in virtual space (like the ancient program loaders).
          • No-manage: allocate and no free
          • (Switch to segment tree)
        • TLB shootdown: IPI required Done!

      • Done! x86-64 IPI call interface

        • Interface: "Invoke some function with a parameter on every CPU core"
        • Interruptable but no preemption (disable preemption: need to modify dependency code?).
          • TODO: disable preemption for a processor. Really required?
        • Not quite required unless remove_module is done (TLB shootdown).
    • Basic LKM support
      • Not necessary to be compatible with Linux interface
        • Linux: Relocatable object based
        • our module: shared-library based
      • Multiple language support
        • "Calling convention": Use C calling convention. (extern "C" no mangle)
        • TODO: /proc/kallsyms alike feature? Linking to arbitrary symbol in kernel (not likely because of mangling).
      • LKM can be bundled into kernel (not quite necessary: a simple bundle is OK.)
      • LKM loader & building tools

        • Basic loading (linking into running kernel, like insmod/delmod)
          • Use shared library as kernel module! Not the same with existing implementations which links relocatable file into kernel.
          • Shared library interface design?
            • Standard shared library.
            • Simple metadata.
          • "Trivial" program
            • Done busybox insmod

          • Remove module
            • Safety? Reference counting on symbol-dependence and feature-dependence (like owner of file_operations in Linux).
            • Plug-out. Simple since TLB-shootdown has been implemented.
        • Loading with dependence (modprobe)
          • Done Simple dependence with reference counting.

          • Automatic dependence loading?
    • A working example
      • Stub needed in the kernel.
      • Which example?
        • hello
        • hellodeps
        • (Possible) audeo-device for aarch64? Gaps and gaps and gaps.
          • aarch64
          • Better device file required.
          • /dev and /proc filesystem: require a good "mount".
  2. (Advanced) shared library support
    • possible mmap support to save memory
    • ASLR support.

实验参与者信息

姓名

学号

电子邮箱

GitHub 账户

郭敬哲

2016011362

guojz16@mails.tsinghua.edu.cn

gjz010

实验代码仓库:

Extensible kernel refactor TODO list

1. Unified filesystem with mounting support.

2. Unified device interface? /sys filesystem and /proc filesystem

  1. PCI tree should be saved.
  2. /sys based on memfs, exporting PCI tree.
  3. Device API?
    • What is a device? Block/Char
      • Should allow driver to discover device in PCI tree (by PCI registering). Should transfer ownership of device to driver.

3. Now we have the power of god, and need to do some god work.

  1. Exporting API in Rust/C form (MODULE_EXPORT)
  2. Port some driver there

已有工作参考

中期报告

lkm-pre-midterm.pptx

13周报告

LoadableKernelModule+.pptx

16周报告

Emmc + SD + Raspberry Pi 3.pptx

总报告

https://gist.github.com/gjz010/8ac0f7ae85938b4cdb7d75874d43efed (需要科学上网)

日志

OS2019spring/projects/g06 (last edited 2019-06-17 18:44:21 by 2016011362)

MoinMoin Appliance - Powered by TurnKey Linux