Có thể hình dung Ubuntu hay Debian như món ăn đã nấu sẵn: bạn nhận về và dùng, thêm bớt chút gia vị bằng trình quản lý gói. Yocto thì trao cho bạn cả căn bếp. Có sách công thức cho từng nguyên liệu (kernel, bootloader, glibc, busybox, systemd, Qt…), có đầu bếp đọc công thức và nấu theo đúng thứ tự phụ thuộc. Món cuối cùng được nấu từ mã nguồn, cho đúng kiến trúc CPU, đúng board, và chỉ có những gì bạn cần. Nhờ vậy một image Yocto có thể nhỏ vài chục MB, hoặc đầy đủ tới mức có giao diện đồ họa và trình duyệt, tùy người thiết kế.

1
yocto-bsp/
2
├── .repo/
3
│   ├── manifests/            ← git repo chứa các file manifest
4
│   ├── manifest.xml          ← manifest đang có hiệu lực
5
│   ├── repo/                 ← mã nguồn của chính công cụ repo
6
│   ├── projects/             ← thư mục .git thật của từng project
7
│   └── project-objects/
8
├── setup-environment         ← sinh ra nhờ <copyfile> trong manifest
9
└── sources/
10
    ├── poky/
11
    │   ├── bitbake/
12
    │   ├── meta/             ← OpenEmbedded-Core
13
    │   ├── meta-poky/
14
    │   ├── meta-yocto-bsp/
15
    │   ├── meta-skeleton/
16
    │   ├── meta-selftest/
17
    │   ├── documentation/
18
    │   ├── scripts/
19
    │   └── oe-init-build-env
20
    ├── meta-openembedded/
21
    │   ├── meta-oe/
22
    │   ├── meta-python/
23
    │   ├── meta-networking/
24
    │   ├── meta-multimedia/
25
    │   └── ...
26
    ├── meta-vendor-bsp/
27
    └── meta-mycompany/

1
meta-mycompany/
2
├── conf/
3
│   ├── layer.conf
4
│   ├── machine/
5
│   │   └── myboard.conf
6
│   └── distro/
7
│       └── mydistro.conf
8
├── recipes-bsp/
9
│   └── u-boot/
10
│       ├── u-boot_%.bbappend
11
│       └── files/0001-add-myboard-support.patch
12
├── recipes-kernel/
13
│   └── linux/
14
│       ├── linux-vendor_%.bbappend
15
│       └── files/
16
│           ├── myboard.dts
17
│           └── enable-feature.cfg
18
├── recipes-apps/
19
│   └── hello/
20
│       ├── hello_1.0.bb
21
│       └── files/hello.c
22
├── recipes-core/
23
│   └── images/
24
│       └── myimage.bb
25
├── COPYING.MIT
26
└── README

1
BBPATH .= ":${LAYERDIR}"
2

3
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
4
            ${LAYERDIR}/recipes-*/*/*.bbappend"
5

6
BBFILE_COLLECTIONS += "mycompany"
7
BBFILE_PATTERN_mycompany = "^${LAYERDIR}/"
8
BBFILE_PRIORITY_mycompany = "10"
9

10
LAYERDEPENDS_mycompany = "core openembedded-layer"
11
LAYERSERIES_COMPAT_mycompany = "scarthgap"

1
SUMMARY = "Hello world example"
2
LICENSE = "MIT"
3
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
4

5
SRC_URI = "file://hello.c"
6
S = "${WORKDIR}"
7

8
do_compile() {
9
    ${CC} ${CFLAGS} ${LDFLAGS} hello.c -o hello
10
}
11

12
do_install() {
13
    install -d ${D}${bindir}
14
    install -m 0755 hello ${D}${bindir}
15
}

1
BBLAYERS ?= " \
2
  ${TOPDIR}/../sources/poky/meta \
3
  ${TOPDIR}/../sources/poky/meta-poky \
4
  ${TOPDIR}/../sources/meta-openembedded/meta-oe \
5
  ${TOPDIR}/../sources/meta-vendor-bsp \
6
  ${TOPDIR}/../sources/meta-mycompany \
7
"

1
MACHINE ?= "myboard"
2
DISTRO ?= "poky"
3
PACKAGE_CLASSES ?= "package_ipk"
4

5
BB_NUMBER_THREADS ?= "8"
6
PARALLEL_MAKE ?= "-j 8"
7

8
DL_DIR ?= "${TOPDIR}/../downloads"
9
SSTATE_DIR ?= "${TOPDIR}/../sstate-cache"

Mọi lệnh gửi xuống đều mang sẵn địa chỉ “gửi tới LU nào”. Nhờ vậy SoC làm việc với nhiều LU cùng lúc, không phải chuyển công tắc như eMMC.

Ref:
[1] https://projectzero.google/2024/12/qualcomm-dsp-driver-unexpectedly-excavating-exploit.html
[2] https://docs.qualcomm.com/securitybulletin/october-2024-bulletin.html

How does the system keep track of the connection between the string filename argv[i] passed to open(), and the resulting integer file descriptor fd? What does the integer file descriptor number refer to?

Câu hỏi này bắt đầu xoay quanh vào implementation ở user/cat.c. Nếu nhìn vào code xử lý của cat

1
if((fd = open(argv[i], 0)) < 0){ ... }
2
cat(fd);
3
close(fd);

Từ các đoạn logic xử lý chính của cat thì có 1 câu hỏi? nếu mình truyền vào 1 string “README” thì làm sao kernel xử lý trả về là 1 interger fd, và mọi câu lệnh xử lý sau đó là số nguyên interger fd chứ không phải là chuỗi README. Nếu vậy thì câu hỏi thật sự cần quan tâm ở đầy là kernel làm sao có thể xử lý được mọi file mà chỉ cần thông qua 1 interger fd là đủ.

Ví dụ, sau khi thực hiện lệnh cat README trên user, thì systemcall open được gọi ra để xử lý. Đầu tiên nó lấy được 2 giá trị thông số là mode permission và chuỗi string README thông qua

1
argint(1, &omode);
2
n = argstr(0, path, MAXPATH)

Phần logic detail làm sao có thể từ user -> kernel sẽ được detail ở blog systemcall. Tư đó mình có dược permission của file và chuỗi README từ kernel.

Có được chuỗi “README” rồi, kernel dùng nó để tìm file thật sự nằm ở đâu:

1
if((ip = namei(path)) == 0){
2
  end_op();
3
  return -1;
4
}
5
ilock(ip);

Ở phần này chỉ cần biết namei nhận vào một chuỗi tên và trả về ip, một con trỏ tới struct inode đại diện cho file đó trong kernel. Cách nó tìm ra inode sẽ có bài riêng. Điều quan trọng là đây là lần duy nhất chuỗi “README” được dùng. Từ đây trở đi, kernel chỉ làm việc với con trỏ ip.

Câu hỏi được chuyển đổi từ README sang fd thành: con trỏ ip sang fd?

Kernel không đưa thẳng ip cho process. Nó bọc ip trong một cấu trúc khác, struct file (kernel/file.h):

1
struct file {
2
  enum { FD_NONE, FD_PIPE, FD_INODE, FD_DEVICE } type;
3
  int ref; // reference count
4
  char readable;
5
  char writable;
6
  struct pipe *pipe; // FD_PIPE
7
  struct inode *ip;  // FD_INODE and FD_DEVICE
8
  uint off;          // FD_INODE
9
  short major;       // FD_DEVICE
10
};

Inode mô tả file. struct file mô tả một lần mở file: đang đọc tới byte thứ mấy (off), được đọc hay ghi (readable, writable). Nếu hai process cùng mở README, cả hai dùng chung một inode nhưng mỗi bên có struct file riêng, nên offset của bên này không ảnh hưởng bên kia.

Để ý trường type: một struct file không nhất thiết là file trên đĩa. Nó có thể là pipe (FD_PIPE) hoặc thiết bị như console (FD_DEVICE). Đây chính là lý do một fd có thể đại diện cho “mọi thứ”.

Tất cả struct file của toàn hệ thống nằm trong một mảng global ftable (kernel/file.c):

1
struct {
2
  struct spinlock lock;
3
  struct file file[NFILE];   // NFILE = 100
4
} ftable;

sys_open gọi filealloc() để lấy một ô trống (ref == 0) trong mảng này:

1
struct file*
2
filealloc(void)
3
{
4
  struct file *f;
5

6
  acquire(&ftable.lock);
7
  for(f = ftable.file; f < ftable.file + NFILE; f++){
8
    if(f->ref == 0){
9
      f->ref = 1;
10
      release(&ftable.lock);
11
      return f;
12
    }
13
  }
14
  release(&ftable.lock);
15
  return 0;
16
}

Mỗi process có một bảng file đang mở của riêng nó, trong struct proc (kernel/proc.h):

1
struct file *ofile[NOFILE];  // Open files, NOFILE = 16

fdalloc tìm ô trống đầu tiên trong mảng này, đặt con trỏ f vào và trả về chỉ số của ô đó:

1
static int
2
fdalloc(struct file *f)
3
{
4
  int fd;
5
  struct proc *p = myproc();
6

7
  for(fd = 0; fd < NOFILE; fd++){
8
    if(p->ofile[fd] == 0){
9
      p->ofile[fd] = f;
10
      return fd;
11
    }
12
  }
13
  return -1;
14
}

Vậy là có câu trả lời: file descriptor chỉ là một chỉ số trong mảng p->ofile[] của process. Không có gì bí ẩn cả.

Với cat, ô 0, 1, 2 đã được dùng cho stdin, stdout, stderr (console), nên README thường nhận fd = 3.

Phần còn lại của sys_open điền thông tin vào struct file vừa cấp:

1
f->type = FD_INODE;
2
f->off = 0;
3
f->ip = ip;
4
f->readable = !(omode & O_WRONLY);
5
f->writable = (omode & O_WRONLY) || (omode & O_RDWR);
6

7
iunlock(ip);
8
end_op();
9

10
return fd;

User chỉ cầm số 3. Mọi thông tin thật (file nào, đọc tới đâu, có quyền gì) đều nằm trong kernel, và số 3 là chìa khóa để tìm lại chúng.

Hàm cat() trong user/cat.c gọi read(fd, buf, sizeof(buf)). Trong kernel, sys_read không cần biết tên file. Nó chỉ cần đổi fd ngược lại thành struct file qua argfd:

1
static int
2
argfd(int n, int *pfd, struct file **pf)
3
{
4
  int fd;
5
  struct file *f;
6

7
  argint(n, &fd);
8
  if(fd < 0 || fd >= NOFILE || (f=myproc()->ofile[fd]) == 0)
9
    return -1;
10
  if(pfd)
11
    *pfd = fd;
12
  if(pf)
13
    *pf = f;
14
  return 0;
15
}

Chỉ là myproc()->ofile[fd], kèm kiểm tra fd có hợp lệ và có đang được mở hay không. Sau đó:

1
uint64
2
sys_read(void)
3
{
4
  struct file *f;
5
  int n;
6
  uint64 p;
7

8
  argaddr(1, &p);
9
  argint(2, &n);
10
  if(argfd(0, 0, &f) < 0)
11
    return -1;
12
  return fileread(f, p, n);
13
}

fileread nhìn vào f->type để quyết định đọc từ đâu:

1
int
2
fileread(struct file *f, uint64 addr, int n)
3
{
4
  int r = 0;
5

6
  if(f->readable == 0)
7
    return -1;
8

9
  if(f->type == FD_PIPE){
10
    r = piperead(f->pipe, addr, n);
11
  } else if(f->type == FD_DEVICE){
12
    ...
13
    r = devsw[f->major].read(1, addr, n);
14
  } else if(f->type == FD_INODE){
15
    ilock(f->ip);
16
    if((r = readi(f->ip, 1, addr, f->off, n)) > 0)
17
      f->off += r;
18
    iunlock(f->ip);
19
  } else {
20
    panic("fileread");
21
  }
22

23
  return r;
24
}

Đây là lời giải cho câu hỏi “làm sao chỉ với một số nguyên mà xử lý được mọi thứ”:

• read(3, ...) với README đi vào nhánh FD_INODE, đọc từ đĩa rồi tăng f->off. Lần read sau sẽ đọc tiếp từ chỗ cũ, dù user không hề truyền offset.
• read(0, ...) từ console đi vào nhánh FD_DEVICE.
• read từ đầu đọc của pipe đi vào nhánh FD_PIPE.

Code của cat giống hệt nhau trong cả ba trường hợp. Sự khác biệt được giấu trong struct file. Nhờ vậy, cat README, cat < README hay echo hi | cat đều chạy được mà cat không cần biết mình đang đọc từ đâu.

Cuối cùng cat gọi close(fd), tức là tháo liên kết ra:

1
uint64
2
sys_close(void)
3
{
4
  int fd;
5
  struct file *f;
6

7
  if(argfd(0, &fd, &f) < 0)
8
    return -1;
9
  myproc()->ofile[fd] = 0;
10
  fileclose(f);
11
  return 0;
12
}

• ofile[fd] = 0 giải phóng ô trong bảng của process. Lần open sau có thể dùng lại số 3.
• fileclose(f) giảm f->ref. Khi ref về 0, ô trong ftable được giải phóng và iput(ff.ip) trả lại tham chiếu tới inode.
• ref cần thiết vì một struct file có thể được nhiều fd trỏ tới cùng lúc, ví dụ sau dup(), hoặc khi fork() copy ofile[] sang process con qua filedup. Chỉ khi không còn ai dùng thì struct file mới thật sự bị giải phóng.

Kernel không “nhớ” liên kết giữa chuỗi “README” và số 3. Chuỗi tên chỉ dùng một lần trong open để tìm ra inode. Sau đó kernel tạo ra một chuỗi con trỏ:

1
fd (int)  →  p->ofile[fd]  →  struct file { type, off, readable, writable, ip / pipe }  →  inode / pipe / device

Và trả cho user chỉ số của mắt xích đầu tiên. Mọi syscall sau đó (read, write, close, fstat, dup) đều bắt đầu bằng cùng một bước: myproc()->ofile[fd].