kernel側のsyscallを書き換える
- user側はあとで考える
kernel側はsyscallに対応したinterfaceを作成する
- syscall　entryで個別にインスタンスを作成するか、呼び出すか

# CbCXv6の実装Todo

generate_stubの修正
KernelのContext
Readsyscall周りの再実装
User側のAPI callをオブジェクト指向的にする

# そこまで優先度たかくない

Interfaceの積を取れるようにする
usbドライバの作成
(Interfaceの多重実装)

# generate_stubの修正

いまのところinterfaceで定義したCodeGearを実装しているうちは正常

Interfaceで定義していない(Implで独自定義したCodeGearの場合)は上手くgoto　metaが変換されない
generate_stubは #interfaceを見ているので、正常に生成される

# Read

~~PipeReadなどを個別のAPI化する~~
- これではなくてFile Interfaceを実装していく

# File Interface

kernel内部で利用している struct fileに着目する
- fileは必ずread, write, close, seekができる
  - これはunixの想定と同じ
xv6では struct fileはNONE, Pipe, INODEの3種類に分類される
その為、 struct fileをInterface化し、 noneなどで実装をする

# image

# Interface

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


typedef struct file <Impl> {
    union Data* file;
    int          ref;   // reference count
    char         readable;
    char         writable;
    unsigned int off;
    struct stat* st;
    char* addr;
    int n;
    __code dup(Impl* file, __code next(...));
    __code stat(Impl* file, struct stat* st, __code next(...));
    __code read(Impl* file, char* addr, __code next(...));
    __code write(Impl* file, char* addr, int n, __code next(...));
} file;

👆がFile Interface
- 既存のfile構造体に、API(=CodeGear)で利用する引数を設定している

# Impl

pipeやnoneなどで実装する

1
2


typedef struyct NoneFile<Impl, Isa> file {
} NoneFile;

👆のような雰囲気の構造体を作成すれば良い

# コンストラクタ

sys_openやsys_readの中で、対象のファイルがなんであるかでインスタンスを切り替える
- system call以外のAPIを生やすのも可能ではある(user側との橋渡し)

# 図にした

@startuml

interface File { ..DataGear.. +union Data* file +union Data* impl ..CodeGear.. __code read() __code write() }

File <|– Inode

class Inode { ..DataGear.. TBD ..CodeGear.. __code readInode() __code writeInode() }

File <|– Pipe

class Pipe { ..DataGear.. TBD ..CodeGear.. __code readPipe() __code writePipe() }

File <|– None

class None { ..DataGear.. TBD ..CodeGear.. __code readNone() __code writeNone() }

@enduml

CbCXv6の実装方針