{"componentChunkName":"component---src-templates-post-template-js","path":"/unix-xv6-010-kernel-main-07-en","result":{"data":{"markdownRemark":{"id":"8f9ed2e0-6abb-55e5-91e6-d1d7820e09ed","html":"
\n

This page has been machine-translated from the original page.

\n
\n

I’m reading xv6 OS inspired by Your First OS Code Reading: Learning Kernel Internals with UNIX V6.

\n

Because UNIX V6 itself does not run on x86 CPUs, I decided to read the source code of kash1064/xv6-public: xv6 OS, a fork of the xv6 OS repository that adapts UNIXv6 to run on the x86 architecture.

\n

Last time, we looked at the picinit and ioapicinit functions executed from main.

\n

This time, I’ll follow the behavior of the consoleinit function.

\n\n

Table of Contents

\n\n

The consoleinit function

\n

The consoleinit function is defined in console.c as follows.

\n
void consoleinit(void)\n{\n  initlock(&cons.lock, \"console\");\n\n  devsw[CONSOLE].write = consolewrite;\n  devsw[CONSOLE].read = consoleread;\n  cons.locking = 1;\n\n  ioapicenable(IRQ_KBD, 0);\n}
\n

First, initlock(&cons.lock, \"console\"); on the first line is the function that initializes the spinlock structure used for the memory lock we looked at in the memory allocation and mutual exclusion article.

\n

The &cons.lock used here is defined as follows.

\n
static struct {\n  struct spinlock lock;\n  int locking;\n} cons;
\n

Incidentally, consoleinit itself does not lock memory.

\n

Instead, memory locking is performed using cons when functions such as consoleread and consolewrite run.

\n

Next, let’s look at the following lines.

\n
devsw[CONSOLE].write = consolewrite;\ndevsw[CONSOLE].read = consoleread;
\n

The devsw referenced here is an array of devsw structures, and this array is defined in file.c.

\n
struct devsw devsw[NDEV];
\n

The devsw structure itself is defined in file.h.

\n
// table mapping major device number to\n// device functions\nstruct devsw {\n  int (*read)(struct inode*, char*, int);\n  int (*write)(struct inode*, char*, int);\n};\n\nextern struct devsw devsw[];\n#define CONSOLE 1
\n

By the way, NDEV is defined as 10 in param.h.

\n
#define NDEV         10  // maximum major device number
\n

About the devsw structure

\n

What I wanted to understand in more detail here was what exactly the devsw structure is.

\n

Looking at UNIX manuals and similar material, the devsw structure seems to be used when device drivers provide character device interfaces.

\n

Reference: devsw(9) - NetBSD Manual Pages

\n

Also, based on the following page, I think character device interfaces correspond to I/O interfaces for devices where the system transfers data one character at a time.

\n

Reference: Device file - Wikipedia

\n

Looking at the definition of the devsw structure here, two kinds of function pointers are set: read and write.

\n

Arbitrary functions are assigned here, as in the consoleinit function.

\n

Both functions take an inode structure as an argument.

\n

Like the devsw structure, the inode structure is defined in file.h.

\n
// in-memory copy of an inode\nstruct inode {\n  uint dev;           // Device number\n  uint inum;          // Inode number\n  int ref;            // Reference count\n  struct sleeplock lock; // protects everything below here\n  int valid;          // inode has been read from disk?\n\n  short type;         // copy of disk inode\n  short major;\n  short minor;\n  short nlink;\n  uint size;\n  uint addrs[NDIRECT+1];\n};
\n

What is an inode

\n

Before going further, I’ll briefly touch on what an inode is.

\n

Roughly speaking, an inode is a structure that stores information about file system objects such as files and directories.

\n

The kinds of information an inode holds include the following.

\n\n

Reference: inode - Wikipedia

\n

If you look at xv6OS’s inode structure, you can see that it stores similar information.

\n

inodes are managed by unique IDs within the system (in xv6OS, inum probably fills that role).

\n

There is usually an upper limit on assignable inode numbers, and if the available inode numbers are exhausted, you can no longer create new files even if there is still free disk space on the storage device.

\n

On a typical Linux system, you can check each device’s inode limit with the df -i command.

\n
$ df -i\nFilesystem                         Inodes  IUsed   IFree IUse% Mounted on\nudev                              1007124    449 1006675    1% /dev\ntmpfs                             1019154    919 1018235    1% /run\n/dev/mapper/ubuntu--vg-ubuntu--lv 1310720 380878  929842   30% /\ntmpfs                             1019154      1 1019153    1% /dev/shm\ntmpfs                             1019154      5 1019149    1% /run/lock\ntmpfs                             1019154     18 1019136    1% /sys/fs/cgroup\n/dev/loop0                             29     29       0  100% /snap/bare/5\n/dev/loop2                          10847  10847       0  100% /snap/core18/2284\n/dev/loop1                          10836  10836       0  100% /snap/core18/2253\n/dev/loop3                          11776  11776       0  100% /snap/core20/1270\n/dev/loop5                          18500  18500       0  100% /snap/gnome-3-34-1804/72\n/dev/loop4                          11777  11777       0  100% /snap/core20/1328\n/dev/loop6                          18500  18500       0  100% /snap/gnome-3-34-1804/77\n/dev/loop7                          65095  65095       0  100% /snap/gtk-common-themes/1519\n/dev/loop8                            796    796       0  100% /snap/lxd/21835\n/dev/loop9                          64986  64986       0  100% /snap/gtk-common-themes/1515\n/dev/loop10                           796    796       0  100% /snap/lxd/21545\n/dev/loop11                           479    479       0  100% /snap/snapd/14295\n/dev/loop12                           482    482       0  100% /snap/snapd/14549\n/dev/sda2                           65536    320   65216    1% /boot\ntmpfs                             1019154     45 1019109    1% /run/user/121\ntmpfs                             1019154     83 1019071    1% /run/user/1000
\n

Reference: What Is an i-node (inode)?

\n

Reading the consolewrite function

\n

At this point, we still are not creating files using inode, so for now let’s return to xv6OS’s code.

\n
devsw[CONSOLE].write = consolewrite;\ndevsw[CONSOLE].read = consoleread;
\n

The write and read fields of the CONSOLE = 1 element in the devsw array are assigned the functions defined in console.c.

\n

First, let’s read the consolewrite function.

\n
int consolewrite(struct inode *ip, char *buf, int n)\n{\n  int i;\n\n  iunlock(ip);\n  acquire(&cons.lock);\n  for(i = 0; i < n; i++) consputc(buf[i] & 0xff);\n  release(&cons.lock);\n  ilock(ip);\n\n  return n;\n}
\n

The consolewrite function takes a pointer to the target inode structure variable, along with the characters to pass to consputc and their length.

\n

First is the iunlock function, which is defined in fs.c.

\n
// Unlock the given inode.\nvoid iunlock(struct inode *ip)\n{\n  if(ip == 0 || !holdingsleep(&ip->lock) || ip->ref < 1) panic(\"iunlock\");\n  releasesleep(&ip->lock);\n}
\n

I’ll look at this function in more detail when I get to the file system, but it releases the lock by manipulating the sleeplock structure held by the passed inode.

\n

Next, after acquiring the lock with acquire, it feeds the passed string into consputc one character at a time.

\n

At this point, the supplied string is ANDed with 0xFF, so only the lower 8 bits are passed along.

\n
void consputc(int c)\n{\n  if(panicked){\n    cli();\n    for(;;) ;\n  }\n\n  if(c == BACKSPACE){\n    uartputc('\\b'); uartputc(' '); uartputc('\\b');\n  } else{\n      uartputc(c);\n  }\n  cgaputc(c);\n}
\n

Here, uartputc is called with the supplied value as its argument.

\n

The uartputc function is defined in uart.c, and it writes to the serial port (UART).

\n

Here, it writes the received value to COM1 (I/O port 0x3f8).

\n
void uartputc(int c)\n{\n  int i;\n\n  if(!uart) return;\n  for(i = 0; i < 128 && !(inb(COM1+5) & 0x20); i++) microdelay(10);\n  outb(COM1+0, c);\n}
\n

COM1+0 is the data register, and writing a value here writes it to the transmit buffer.

\n

The previous line, inb(COM1+5), reads the value of the line status register.

\n

The sixth bit of the line status register is called THRE, and when this bit is set, it means the transmit buffer is empty and ready to send new data.

\n

Reference: Serial Ports - OSDev Wiki

\n

In other words, the line !(inb(COM1+5) & 0x20) checks the THRE bit in the line status register, and if the transmit buffer is not available, it delays processing with the microdelay function.

\n

By the way, when BACKSPACE is entered, the sequence uartputc('\\b'); uartputc(' '); uartputc('\\b'); seems to mean: move the cursor back one position, overwrite that position with a space, and then move the cursor back once more to the position before the write.

\n

Writing to video memory

\n

Once writing to the serial port is done, the cgaputc function is called at the end.

\n

cgaputc writes the input value to video memory and displays it.

\n
static void cgaputc(int c)\n{\n  int pos;\n\n  // Cursor position: col + 80*row.\n  outb(CRTPORT, 14);\n  pos = inb(CRTPORT+1) << 8;\n  outb(CRTPORT, 15);\n  pos |= inb(CRTPORT+1);\n\n  if(c == '\\n') pos += 80 - pos%80;\n  else if(c == BACKSPACE){\n    if(pos > 0) --pos;\n  } else{\n    crt[pos++] = (c&0xff) | 0x0700;  // black on white\n  }\n  if(pos < 0 || pos > 25*80) panic(\"pos under/overflow\");\n\n  if((pos/80) >= 24){  // Scroll up.\n    memmove(crt, crt+80, sizeof(crt[0])*23*80);\n    pos -= 80;\n    memset(crt+pos, 0, sizeof(crt[0])*(24*80 - pos));\n  }\n\n  outb(CRTPORT, 14);\n  outb(CRTPORT+1, pos>>8);\n  outb(CRTPORT, 15);\n  outb(CRTPORT+1, pos);\n  crt[pos] = ' ' | 0x0700;\n}
\n

The crt destination used here points to the region at address 0xb8000.

\n

This region is called the frame buffer.

\n
//PAGEBREAK: 50\n#define BACKSPACE 0x100\n#define CRTPORT 0x3d4\nstatic ushort *crt = (ushort*)P2V(0xb8000);  // CGA memory
\n

Reference: What Is a Frame Buffer? - e-Words IT Dictionary

\n

Reference: 3.-The Screen

\n

First, CRTPORT points to 0x3D4, the register of the CRT Controller.

\n

This is a control register, and the data register area corresponding to 0x3D4 is 0x3D5.

\n

Using these two regions, you can control the cursor position on the console.

\n

Setting 14 in 0x3D4 selects control of the upper 8 bits of the 16-bit cursor value.

\n

Setting 15 selects control of the lower 8 bits of the cursor value.

\n

In other words, the following lines store the current 16-bit cursor position in the variable pos.

\n
outb(CRTPORT, 14);\npos = inb(CRTPORT+1) << 8;\noutb(CRTPORT, 15);\npos |= inb(CRTPORT+1);
\n

The relationship between the upper and lower bits of the cursor value obtained here is shown below.

\n

The upper 8 bits indicate the cursor’s row position, and the lower 8 bits indicate the column position.

\n

\n \n \n \n \n \n \n \n \n

\n

The following line defines the behavior when a newline character is passed.

\n
if(c == '\\n') pos += 80 - pos%80;
\n

It increments pos so that the cursor moves to the leftmost position of the next line.

\n

If BACKSPACE is given, the cursor position is moved back by one.

\n

When ordinary character input is given, 16-bit character data is stored.

\n
else if(c == BACKSPACE){\n  if(pos > 0) --pos;\n} else{\n  crt[pos++] = (c&0xff) | 0x0700;  // black on white\n}
\n

The upper 8 bits of this character data hold the background and text color information.

\n

The lower 8 bits specify the character to display.

\n

\n \n \n \n \n \n \n \n \n

\n

Reference image: 3.-The Screen

\n

If you check it in the debugger, you can confirm that this processing actually displays characters on the console.

\n

\n \n \n \n \n \n \n \n \n

\n

The next processing is very simple: if the output exceeds the maximum of 24 lines, it removes the first line, scrolls up, and makes the last line blank.

\n
if((pos/80) >= 24){  // Scroll up.\n  memmove(crt, crt+80, sizeof(crt[0])*23*80);\n  pos -= 80;\n  memset(crt+pos, 0, sizeof(crt[0])*(24*80 - pos));\n}
\n

Finally, the current cursor position is saved to CRTPORT and CRTPORT+1.

\n
outb(CRTPORT, 14);\noutb(CRTPORT+1, pos>>8);\noutb(CRTPORT, 15);\noutb(CRTPORT+1, pos);\ncrt[pos] = ' ' | 0x0700;
\n

With that, writing to the console via the consputc function is complete.

\n

After returning to consolewrite, it releases the memory lock and locks the inode, then finishes.

\n
release(&cons.lock);\nilock(ip);
\n

Reading the consoleread function

\n

Next, I’ll read the consoleread function.

\n

The consoleread function takes an inode, a pointer to the read destination, and the buffer size to read as arguments.

\n
int consoleread(struct inode *ip, char *dst, int n)\n{\n  uint target;\n  int c;\n\n  iunlock(ip);\n  target = n;\n  acquire(&cons.lock);\n  while(n > 0){\n    while(input.r == input.w){\n      if(myproc()->killed){\n        release(&cons.lock);\n        ilock(ip);\n        return -1;\n      }\n      sleep(&input.r, &cons.lock);\n    }\n    c = input.buf[input.r++ % INPUT_BUF];\n    if(c == C('D')){  // EOF\n      if(n < target){\n        // Save ^D for next time, to make sure\n        // caller gets a 0-byte result.\n        input.r--;\n      }\n      break;\n    }\n    *dst++ = c;\n    --n;\n    if(c == '\\n')\n      break;\n  }\n  release(&cons.lock);\n  ilock(ip);\n\n  return target - n;\n}
\n

As with consolewrite, after releasing the memory lock and the inode lock, it performs the following processing inside a loop over the specified buffer size.

\n
c = input.buf[input.r++ % INPUT_BUF];\nif(c == C('D')){  // EOF\n  if(n < target){\n    // Save ^D for next time, to make sure\n    // caller gets a 0-byte result.\n    input.r--;\n  }\n  break;\n}\n\n*dst++ = c;\n--n;\nif(c == '\\n') break;
\n

The input structure is the following structure.

\n
#define INPUT_BUF 128\nstruct {\n  char buf[INPUT_BUF];\n  uint r;  // Read index\n  uint w;  // Write index\n  uint e;  // Edit index\n} input;
\n

It seems to read out the values stored in this input structure one character at a time.

\n

In practice, this processing is not called until after the OS has finished booting.

\n

More specifically, it is used when reading characters entered into the shell.

\n

The following image shows what I observed in the debugger when I typed the character l into the console.

\n

\n \n