Add Week14 log

Signed-off-by: Rafi Muhammad Daffa <rafi.muhammad81@ui.ac.id>

week-14/1806141422_rafi_week_14.md

-# Systems Programming
+# Week 14 Logbook
+
+**Name**: Rafi Muhammad Daffa | **Class**: A | Systems Programming (**CSCM603127**)
+
+## Topics
+
+1. Listing Loaded Kernel Modules
+2. Class vs Device
+3. Built-in vs Modularized Device Drivers
+4. Inserting / Removing Modularized Device Drivers
+5. Controlling Device Drivers
+6. Passing Parameters to Built-in Device Drivers
+
+## Notes
+
+### Listing Loaded Kernel Modules
+
+This method is useful to query which kernel modules (especially modularized device drivers) are currently loaded in the system. The name of the module itself is usually intuitive enough to be used to indicate whether a device is currently loaded or not. This can be achieved through this command:
+
+~~~shell
+lsmod
+~~~
+
+To anticipate lengthy output, it is wise to use **lsmod** along with applications such as **more** or **less**. If we specifically target a specific module to inquire whether that module is loaded or not, we can use **grep** to filter the output. For example, if we want to check whether the ethernet device driver is loaded or not, we can use:
+
+~~~shell
+lsmod | grep e1000
+~~~
+
+![image-20201222150921918](assets/image-20201222150921918.png)
+
+However, **lsmod** only shows brief information regarding the modules that are loaded (which includes the module name, size, and who uses the module). If we want to go through the information of a particular module, we instead need to use the **modinfo** command as shown below:
+
+~~~shell
+# Format: modinfo <module name>
+modinfo e1000
+~~~
+
+![image-20201222154132446](assets/image-20201222154132446.png)
+
+There are some information that we can dig from this information, for example:
+
+1. The location of the module source code in the kernel module tree
+2. The license for the kernel module
+3. The description of the kernel module
+4. The author of the kernel module
+5. The source version
+6. Some aliases that the drivers use to refer to the devices
+7. Kernel module dependencies
+8. Kernel module name
+9. Signature for the kernel module (a lack of which will taint the kernel if that module is loaded)
+10. Kernel module parameters which can be passed to alter the behavior of the kernel module
+
+### Class vs Device
+
+Device refers to the actual tangible tool (either physical or virtual) that we are going to use through drivers. Examples of devices are **loop** (Loop device), **e1000** (Intel Ethernet device), and **snd_intel8x0** (Intel Audio soundcard device). Every device has a unique entry in the **/dev** directory which can be used to interface with the device itself, in line with the notion in Linux that "everything is a file" or, in this case, "every device has a file representation in the filesystem hierarchy". For example:
+
+![img](assets/devloop.png)
+
+In the example above, we can see that all loop devices that are created by the **loop** device driver has a unique representation in the **/dev** folder structure. Each of them has the attribute "b" which stands for block device, which is the type of device that **loop** belongs to, which brings us to classes.
+
+Classes signify a group of device that have similar characteristics and are deliberately structured as such. The grouping of class usually shows a correlation of purpose, similarity of structure, and others. It can also show a group of devices that are controlled by a single driver. For example, if we modify the device driver in Week 13 to create multiple devices under the same class, this falls under the category of "same driver, same class". Each class has a unique directory under the **/sys/class** directory which contain pointers to the devices belonging to that class. For example, **loop** devices belong to the **block** class which shows that they are block devices. A query to the **/sys/class** directory confirms the membership as shown below:
+
+![img](assets/sysclass.png)
\ No newline at end of file