Figuring out low-level stack for novel architectures[PATH]

This isn’t just another roadmap but my personal low-level learning path(which will never end I know) that I have been following while figuring out complete end-to-end low-level stack for a novel computing architecture based on memristors in-memory brain-inspired chip.

Questions to answer:

  • “How does userspace talk to hardware?”
  • “Where do syscalls actually live?”
  • “How would my neuromorphic accelerator appear to Linux?”
  • “How does the kernel map physical devices to memory?”
  • “How would I add a new instruction or device?”
Linux System Programming  
        ↕
Practical C Programming   
        ↕
Linux Device Drivers     
        ↕
Linux Kernel Development  
        ↕
Computer Architecture

Linux System Programming – Robert Love

Chapters first:

  • Process model
  • Syscalls
  • Files & file descriptors
  • Memory mapping (mmap)
  • Signals

Questions:

  • “What syscall would my accelerator need?”
  • “Would my chip be accessed via /dev/... or mmap?”

Hands on exercise:

// write small programs that:
open("/dev/…")
mmap() a fakedevice(using /dev/zero)
read/write memory regions

This maps directly to my crossbar physical address questions.

Chapter 1: Introduction and Essential Concepts

Mental map b/w these:

  • user space
  • libc
  • kernel
  • hardware
  • What is really a system call?
  • Where does libc end and the kernel begin?
  • Why doesn’t userspace talk to hardware directly?
  • What abstractions does Linux force on hardware?
strace ls
strace echo hello
  • Which calls cross the user/kernel boundary?
  • Which are libc-only?

The neuromorphic chip will never be accessed directly — it will appear as:

  • a file
  • memory mapping
  • or ioctl interface

This chapter sets that expectation.

Chapter 2: File I/O

This is the most important chapter in the entire book. Linux’s worldview:

“Everything is a file (or pretends to be).” Our chip will be a file.

Questions to answer:

  • Why are file descriptors integers?
  • How does read() know what hardware to talk to?
  • How does the kernel dispatch a read() to the right driver?
  • What happens after open("/dev/xxx")?

Special attention to

  • open, read, write, close
  • File offsets
  • Blocking vs non-blocking I/O

Kernel-implementation section (important!)

When the chapter explains how the kernel manages files: Don’t memorize structures just understand flow.

read() →
  VFS →
    file_operations →
      driver callback

Hands-on

  1. Write a C program that:
    • opens a file
    • reads raw bytes
    • prints hex output
  2. Then try:
open("/dev/zero")
open("/dev/null")
open("/proc/cpuinfo")

Questions:

  • Why do these behave differently?
  • Why does /proc not behave like a disk file?

Direct relevance to neuromorphic chips

The accelerator will register callbacks for:

  • read

  • write

  • mmap

    exactly like this chapter describes

Chapter 4: Advanced File I/O

This chapter is directly tied to our crossbar / physical address question.

Absolute must-read sections

  • mmap
  • Memory-mapped I/O
  • Avoiding seeks
  • I/O scheduling (high level)

Questions to answer in mind

  • How does a file become memory?

  • What does it mean to map physical memory into userspace?

  • How does Linux prevent unsafe access?

  • Why is mmap preferred for accelerators?

Hands-on (IMPORTANT)

  1. Write a program that:
fd = open("file", O_RDWR);
ptr = mmap(...);
ptr[0] =42;
  1. Repeat using:
/dev/zero
  1. Observe:
  • no read/write syscalls
  • direct memory access

This is the exact mechanism used by:

  • GPUs
  • NICs
  • NPUs
  • neuromorphic accelerators

Chapter 5: Process Management

Why this matters

Accelerators don’t run alone, processes compete.

Read with these questions

  • What is a process from the kernel’s POV?
  • How does a process own memory?
  • How do multiple processes share a device?

Focus on

  • fork
  • exec
  • process lifecycle

Skip(read if you are curious)

  • Detailed scheduling policies
  • Rare process flags

Hands-on

Write:

  • a parent process
  • multiple children
  • all accessing the same file descriptor

Ask:

  • Who owns the device?
  • What happens on concurrent access?

Chapter 6: Advanced Process Management

Only read if:

  • You care about real-time neuromorphic workloads
  • You want deterministic latency

Questions

  • What is real-time scheduling?
  • Why does Linux not guarantee hard real-time?

This connects later to:

  • RTLinux
  • PREEMPT_RT
  • neuromorphic timing constraints

Chapter 8: Memory Management

This chapter + Chapter 4 = accelerator interface mastery.

Read with these questions

  • What is a virtual address vs physical address?
  • Who owns physical memory?
  • How does userspace get memory safely?
  • Why can’t userspace see physical addresses?

Focus on

  • Address space
  • Pages
  • brk, mmap
  • Page faults

Hands-on

Write code that:

  • allocates large memory
  • touches it slowly
  • observe page faults via perf or /proc

This explains why our crossbar needs a kernel driver

Userspace cannot touch physical hardware safely.

Chapter 9: Signals

Read only to answer

  • How does the kernel notify a process asynchronously?
  • How do drivers signal events?

Think:

  • “Interrupt → kernel → signal”

Chapter 10: Time

Read if:

  • timing matters
  • spike-based computation
  • latency benchmarking

Linux Device Drivers (This Is Where The Chip Lives)[IMPORTANT]

Read in this order:

  1. Driver model overview
  2. Character devices
  3. mmapable devices
  4. Interrupt handling
  5. Platform devices / device tree

Constantly ask:

  • “If my neuromorphic chip were real silicon, how would Linux see it?”
  • “What registers would I expose?”
  • “How would userspace control it?”

This directly connects to:

  • memory-mapped I/O
  • your crossbar physical address confusion
  • accelerator programming models

Practical C Programming (Use it as a Reference, not a Book)

  • Read only:
    • Pointers & memory layout
    • Structs, bitfields
    • Undefined behavior
    • Preprocessor & macros

“Why does my low-level code behave weirdly?”

Whenever something feels unclear in kernel / drivers → jump here.

Computer Architecture (Patterson & Hennessy)

Focus chapters:

  • Instruction set architecture (ISA)
  • Memory hierarchy
  • Address translation (MMU, TLB)
  • I/O and memory-mapped devices

You’re literally designing:

  • custom instructions
  • accelerators
  • crossbars
  • memory-mapped hardware

This book tells you how CPUs expect hardware to behave.

Linux Kernel Development – Robert Love

Pre-requisites:

  • You understand syscalls
  • You understand process & memory basics

How to read it:

  • Read conceptually, not implementation-heavy
  • Focus on:
    • Kernel architecture
    • Process scheduling (high level)
    • Memory management overview
    • Interrupts

The Correct Hands-On Strategy (Critical)

Don’t “practice everything”

Instead, build one vertical project:

Expose a fake neuromorphic accelerator to Linux

Minimal project:

  1. Write a simple kernel module
  2. Register a character device /dev/neuro0
  3. Expose fake registers via mmap
  4. Control it from a C userspace program

This single project will:

  • Force you to touch all 5 books
  • Teach more than 6 months of passive reading