Making the Linux Kernel For Fedora 7 – Instructions and Log

[This post has been created from documents last updated in Feb. 2008]

Making the Linux Kernel For Fedora 7 – Instructions

1) rpm -ivh kernel-2.6.21-1.3194.fc7.src.rpm

(Ignore kojibuilder errors)

2) rpm -ivh sparse-0.4.1-1.fc7.i386.rpm

3) rpmbuild -bp –target=$(uname -m) /usr/src/redhat/SPECS/kernel-2.6.spec
Now have a look at the /usr/src/redhat/BUILD directory. It will have two source trees under a kernelxxx directory.

4) cd /usr/src/redhat/BUILD/kernel-2.6.21/linux-2.6.21.i686

6) If you want to save the current .config then copy/rename it as say .saveconfig. Run ‘make mrproper’ (which among other things, deletes .config).

5) cd to configs/ and then copy kernel-2.6.21-i686.config to ../.config OR use saved config file by renaming it to .config

7) Run ‘make menuconfig’. Change configuration as desired
If X-Windows is available then you can run ‘make xconfig’ instead.
See impact of selections here in the remarks on make modules_install (13).

8) Run ‘make dep’ to set up dependencies. [Seems that this step is not required for 2.6 kernel; was required for 2.4 kernel. But run it anyway.]

9) Run ‘make clean’ to prepare the source tree for the build.

10) Ensure that Makefile in linux-2.6.21.i686/ has ‘EXTRAVERSION=something’. This something is appended to the kernel file that is created and so helps in differentiating between current kernel and newly created kernel. This something is also used as a library name for the modules created in the new build.

11) Run ‘make bzImage’ to make the new kernel (vmlinux) [Takes a long time]
Check the size of the vmlinux file (kernel file) that has been created.

12) Run ‘make modules’ to make the new modules. [Takes a very long time]

13) Run ‘make modules_install’ to install new modules in proper path (/lib/modules/<kernelversion>/kernel/drivers
For a config where no changes were made while running make menuconfig, the /lib/modules/<kernelversion>/ directory reported a size of around 441 MB whereas the installed FC7 kernel on my VM (probably default options) had a /lib/modules/<kernelversion>/ directory of size around 52 MB.
And, obviously, the ‘make modules’ command for ‘no changes while running make menuconfig’ config took a huge amount of time. Maybe 1.5 to 2 hours.
So it is very advisable to spend some time at the ‘make menuconfig’ stage and drop the obviously unnecessary modules (for our needs) from the kernel (modules) build.

14) Run ‘make install’ to copy new kernel and its files to proper location.
For my kernel build, the command reported ‘end_request: I/O error, devfd0….’ but it seemed to have copied the kernel to the /boot location. So things may be OK even with the reported error.

15) Verify that /boot directory contains a vmlinuz (compressed version of vmlinux) file whose filename contains the custom kernel version number (picked up from EXTRAVERSION of Makefile)

16) Verify that /boot directory contains an initrd file whose filename reflects the custom kernel version.

17) Verify that /boot/grub/grub.conf has an entry for the custom kernel

Now you are ready to reboot. From the boot (grub) menu choose the custom kernel and try it out.
Note that you can use ‘uname -r’ command to confirm that your custom kernel is running

Log of other attempt(s)

Later I created another kernel but a minimal one. Went through same procedure on existing .config file (and so of prep kernel). Started with ‘make mrproper’ step. Unusually though ‘make menuconfig’ on existing .config file showed a sensible set of options chosen (as against almost all options for prep kernel). I expected existing .config file to show almost all options selected as that is how I ended up with 441 MB of modules!! Gave kernel suffix as min1 (in Makefile as well as in one of the ‘make menuconfig’ options. The .config file has been saved in the FC7 directory as .config.min1 (To be done)

a) ‘make bzImage’ took 10 minutes.
b) ‘make modules’ got over very fast (Maybe less than 3 minutes)!!!! Only a few modules (smb, mymodule etc.) got made. When I checked the .config file the =m option was only for SMB_FS. Maybe that’s why it got over so fast. Have still not understood how the config file is so vastly different from the first (prep) kernel one, though I don’t seem to have made any significant changes while running ‘make menuconfig’. SMB_FS was one of the changes and it got reflected in the build.
When I ran ‘make mrproper’ it gave some CLEAN xxx messages and took quite some time. ‘df’ reported much higher free space after ‘make mrproper’ finished. So I do think that old modules would have got deleted as part of ‘make mrproper’. The ‘make clean’ step ran very quickly (probably because ‘make mrproper’ had done the cleaning).
c) ‘make modules_install’ finished in a few seconds. It created a dir /lib/modules/2.6.21-min1min1 (I guess min1 appears twice due to Makefile entry as well as config entry).
/lib/modules/2.6.21-min1min1 occupies just 136 KB!!!!.
Contrast this with /lib/modules/2.6.21-1.3194-fc7 occupying 57268 KB.
And with /lib/modules/2.6.21-prep occupying 441108 KB.
d) Booting into new (min1min1) kernel failed!!!! After uncompressing Linux it gave an error:
‘powernow-k8: BIOS error – no PSB or ACPI _PSS objects’
and then just froze.
The powernow-k8 error appears on other kernel boots (checked with prep kernel) as well. So that is not be the problem.
Maybe I need to do a kernel rebuild from the rpmbuild step and not the ‘make mrproper’ step.

Noticed that ‘make mrproper’ deletes .config file!!!! So the copy from configs/kernelxxxi686.config is useless. Running ‘make menuconfig’ creates a .config file with those minimal options. Last time I had changed some entries. This time I will leave it untouched and try building kernel again.
Failed again. But this time there was a message prior to the powernow-k8 message saying something about processor not being Intel. I need to check the config file.

Config file mentioned processor as Pentium III. Changed it to AMD in make menuconfig and am trying ‘make bzImage’ again.
Failed again with same message: (microcode: CPU0 not a capable Intel processor followed by powernow-k8 message and then freeze).

I guess I need to repeat the steps right from step 1 (rpm install of source followed by rpmbuild).

Deleted min1 kernel files and /lib/modules files. Emptied redhat/BUILD and redhat/SOURCES and redhat/SPECS directories.
Am now starting at step 1.
Step 3 (rpmbuild) creates a .config file in BUILD/kernxxx/linuxxxx directory. diff between this .config and configs/kernxx-i686.config gave only one extra line in former ( # i386). Renamed .config to .config.orig and carried out step 5 (copying configs/kernxx-i686.config as .config)

‘make mrproper’ deleted .config file!!! So earlier step 5 work was undone!!! So maybe this is the problem step. RH9 kernel needs this but the IBM tutorial for FC7 does not mention this step.

‘make menuconfig’ gave a set of options (maybe its default as there was no .config file). Saved these options. diff between new .config and .config.orig threw up lots of difference. One key difference was that .config had CONFIG_MPENTIUMIII=y whereas .config.orig had CONFIG_M686=y.
I think this is the incorrect specification that tripped up the earlier min1 and min1min1 builds.

Am deleting .config and copying .config.orig as .config. then will run ‘make menuconfig’ again.
Yes. The options in menuconfig match with what I had seen in the prep build. So looks like I may not have done the ‘make mrproper’ step while doing the prep build.
Need to reduce selections (else will have 441 MB of /lib/modules). Plan to try mv .config as .config.orig and then run ‘make menuconfig’. In default .config choose 686. Maybe this will fix problem. (Earlier I had tried AMD instead of PentiumIII – that did not work – see above notes). 686 choice is not there in menuconfig – instead the choice is for 586 or 686 which I chose and that resulted in CONFIG_M586=y spec.
Changed Makefile EXTRAVERSION to min1, make dep, make clean
Now am running make bzImage
Then ran Make modules, make modules_install (0 modules created).

make install tripped up towards end as it attempted to write to fd0. I think Floppy needs to off in VMware while running make install.

System got hung and on restart as there was a min1 option, I tried it out. No luck got same error as earlier.
Am going to try to do make install again with Floppy off.
No luck again!!! Same problem.

Next option is to use the configs/kernxxxi686.config and then run menuconfig on it. This configuration is a safe working starting point. I can then deselect items that I am sure are not needed like IrDA and Bluetooth. I think this approach has a better chance of working. Perhaps using menuconfig without any config file gives it a default set which may not be appropriate for my machine.

Tried this option out at college. /lib/modules/xxxprep takes only about 95 MB.
System goes beyond eariler point but does not find /dev/root and results in ‘kernel panic.’

Back to Home.
‘make defconfig’ creates a .config file with default values. Tried it out. The .config file created had much lesser options that configs/kernxx.i686.config. Processor chosen is Pentium III. Am trying make with the default config now.
Oops!! Got the same error as when ‘make menuconfig’ created the .config file. Makes sense as defconfig option would be what make menuconfig runs to create a base .config if a .config is not present.

BTW found that menuconfig option PentiumPro corresponds to M_686

Noted that /boot has a config file for fc7 install build. That is the same (but for 2 lines of comments) as configs/kerxxxi686.config!!!! Further the prep kernel (whose config was perhaps an exact copy of configs/kernxxxi686.config) is 1883668 bytes and the fc7 kernel is 1883604 bytes. A difference of just 64 bytes. The /lib/modules significant size difference could be due to installation options where only required modules got copied from install media to hard disk.

That means that the better way to customize kernel would be to start with configs/kernxxi686.config and try to remove some entries (as against using defconfig). Tried it out. Reduced many modules but allowed all LVM/RAID modules. Removed only modules that seemed very safe to remove. Reboot into new kernel worked!!!! Finally. Saved the config file as .configmin1-1W. vmlinuz is 1.59 M as against 1.88 M of both prep and fc7. /lib/modules is 276M as against 441M of prep and 57M of fc7 (But I think fc7 lib size is small due to some modules not being copied from distro media to disk).

Now will try to reduced some more modules.

Tried make bzImage after changing config via make menuconfig. make bzImage seems to be compiling everything. I guess changing the config file implies that all files should be made again. To be on safer side I think I should do ‘make clean’ after every config file change. To save time I have made quite a few reductions to the config file. Hope the new kernel runs.
It does!! vmlinuz is 1.50M and /lib/modules/xxxmin1 is 215M. Saved config file as .configmin1-2W
Startup threw up errors for bluetooth and something else (as its drivers are not included). some rpc stuff also gave an error but cannot link it to a missing driver. Ran ntsysv to not start bluetooth, nfslock, sendmail etc. at startup.

Have copied config files to guest and then Windows partition.

Now will try for a final reduction (am running out of time and further now I have got enough hang about it to teach the students). Worked!!!
vmlinuz is 1.42 M and /lib/modules/xxxmin1 is 72M (only)!!. Saved config file as .configmin1-3W.
Startup threw some more errors this time around. IPv6 module has been dropped and so some startup programs failed. IPv4 is present and X-Windows operates fine. Further I have been able to ftp between XP host and OS running this kernel.

There definitely is scope for further reduction in modules. But I guess I need to stop now. An interesting possibility for trying out reduction is to go through /lib/modules/xxxmin1 and check out possible candidates for reduction. To confirm possibility of reduction we can check against lsmod which will give us currently loaded modules. If it is not present there (and also does not seem to an obviously necessary module like ext3fs) then the file (xxx.ko) can be renamed and then the system rebooted. If the system starts up properly then maybe that module can be dropped from config (this assumes that kernel worries only about modules it needs during start up). This way avoids a time consuming kernel rebuild.
A comparison with lib/modules of fc7 may also help in identifying required modules. modinfo command helps in getting detailed info about modules (man modinfo for more details). In fact now I feel this technique can be very promising to reduce modules to way below 57 MB of fc7.

Note: For failed boots I should have looked at dmesg (System log). System log has more info that what is put out on the screen during boot.

Miscellaneous Info.
0) uname -r gives kernel release. man uname for more info
a) free command shows free physical memory.
b) top command gives free memory and some more details.
c) arch command outputs processor architecture
d) Read /usr/src/redhat/BUILD/kernel-xxx/linux-xxx/Documentation/HOWTO. It is a quick intro for a wannabe Linux Kernel Hacker (Developer :-)).
Another must read is kernel-docs.txt in the same directory.
e) lsmod, insmod, modprobe, modinfo are module related commands. man them for info.
lsmod followed by modinfo module-name is a good combo.
f) /etc/modprobe.conf has some module related stuff
g) man bootparam gives info about boot parameters.
h) ???To UPDATE for FC7???kernel customization can reduce vmlinuz size to less than 1 MB. Running system takes up about 5 MB less with casual reduction during customization and /lib/modules/kernel-xxx goes down from 29 MB to around 12 to 13 MB.
Non GUI RH9 can run in 32 MB RAM quite comfortably. ?????
i) In /etc/inittab set default runlevel to 3 for console linux and 5 for GUI linux.
j) cat /proc/cpuinfo is an interesting command. Try it out.
k) lspci -v (another interesting command: lists pci devices)
l) dmesg | more shows the boot up messages.
m) cat /proc/interrupts shows enabled interrupts. man proc details the information accessible from the /proc pseudo filesystem.
n) ntsysv is the text mode command for controlling services startup/configuration.
o) Read /usr/src/linux-xxx/Documentation/CodingStyle

Making FC7 modules – log

Note: The directory FC7/kern-drivers-misc (in the directory containing this file) contains the modules source code and Makefile referred to in the Notes below. Their state is as it was after all notes (points) had been carried out.

1) On FC7 kernel will all modules in default i686 config, tried out mymodule.c module suggested in IBM Linux Kernel hacking tutorial. Notes are:

a) Have to comment out #include <linux/config.h> for successful compilation
b) ‘make modules’ takes some time (around 10 to 15 minutes maybe). Perhaps the large number of modules selected has something to do with the time taken. Even if the other modules are not compiled maybe something else needs to be done which takes time.
c) make modules success results in creation of mymodule.ko module file.
d) The SUBDIRS=xxx argument to make did not work. So either one can say:

i) ‘make modules’ at the top of the build tree, OR
ii) make -C /usr/src/redhat/…. modules

e) Was able to successfully load mymodule and unload it as well.

2) Now am trying referring to variable in other kernel code from mymodule.c. Notes are:

a) After adding code to kernel (printk.c – addition of my_variable global variable), compiled kernel with ‘make bzImage’
b) To install new kernel used ‘make install’ and noted that new kernel image in /boot has current timestamp.

old version of this kernel is stored with .old suffix in /boot
grub.conf does not have additional entry for xxx.old linux kernel, as expected.

c) rebooted into new kernel. Confirmed that code change is reflected by using:

i) grep my_variable System.mapxxxx (in /boot directory)
grep lists the symbols in the new System.mapxxxx file but does not list it in the Sytem.mpaxxxx.old file

d) Added code to mymodule.c (which refers and increments my_variable symbol)
e) Ran ‘make modules’ (took 10 minutes).
f) Loaded & unloaded the module a few times. The my_variable kernel variable was getting changed as expected.

3) Wrote myirqtest.c as instructed. Notes are:

a) Compilation failed. Was able to correct compilation errors by looking at other files in drivers/misc directory. The fixes are:

i) module_param(varname, int/charp, 0644)
instead of MODULE_PARM(varname, “i”/”s”);
ii) myinterrupt function does not take the third struct pt_regs argument. i.e. only first two args (int, void *)

b) Test with irq 18 (interface eth0) succeeded. We can use any interface name, say Saieth0. cat /proc/interrupts then lists it as well.
c) Test with floppy irq (7) and timer irq (0) resulted in insmod failure with mismatch error message.
d) Test with i8042, irq (1) succeeded. Seems to be related to keyboard as pressing a key seems to fire two interrupts.
e) Ran startx to see if more interrupts are listed under /proc/interrupts once X is in operation. X did not seem to add new interrupt (handlers).
f) Under X, tested with i8042, irq(12) which seems to be mapped to the mouse. Test succeeded. Moving mouse resulted in print messages. (Had to use dmesg | tail to see the messages under X, whereas on console the messages appeared on console itself and could additionally be viewed using dmesg | tail).
g) Exited X and retested with i8042, irq(12). Succeeded again and confirmed that irq 12 was mapped to mouse.

4) Modified myirqtest.c to print interrupt count (received by this module) as well. Notes are:

a) Took only 7 minutes to ‘make modules’.
b) Tests succeeded – now the count is also printed and thereby makes it easy to know the last (10th) interrupt print message.

 

———— Old Making RH9 Kernel ———-
1) Check whether /usr/src/linux-2.4 exists.
If not then check whether kernel-source package has been installed using:
rpm -q kernel-source
If this command does not list any kernel-source package then install the kernel-source package using:
rpm -ivh kernel-source-2.4.20-8.i386.rpm

2) cd /usr/src/linux-2.4

3) From /usr/src/linux-2.4/configs copy kernel-2.4.20-i686.config to /usr/src/linux-2.4/.config

4) Run ‘make mrproper’.

5) Run ‘make menuconfig’ (from /usr/src/linux-2.4 directory). Change configuration as desired
If X-Windows is available then you can run ‘make xconfig’ instead.

6) Run ‘make dep’ to set up dependencies. [Takes some time]

7) Run ‘make clean’ to prepare the source tree for the build.

8) Ensure that Makefile in /usr/src/linux-2.4 has ‘EXTRAVERSION=something’. This something is appended to the kernel file that is created and so helps in differentiating between current kernel and newly created kernel. This something is also used as a library name for the modules created in the new build.

9) Run ‘make bzImage’ to make the new kernel (vmlinux) [Takes a long time]
Check the size of the vmlinux file (kernel file) that has been created.

10) Run ‘make modules’ to make the new modules. [Takes a very long time]

11) Run ‘make modules_install’ to install new modules in proper path (/lib/modules/<kernelversion>/kernel/drivers

12) Run ‘make install’ to copy new kernel and its files to proper location.

13) Verify that /boot directory contains a vmlinuz (compressed version of vmlinux) file whose filename contains the custom kernel version number (picked up from EXTRAVERSION of Makefile)

14) Verify that /boot directory contains an initrd file whose filename reflects the custom kernel version.

15) Verify that /boot/grub/grub.conf has an entry for the custom kernel

Now you are ready to reboot. From the boot (grub) menu choose the custom kernel and try it out.
Misc
——–
0) uname -r gives kernel release. man uname for more info
a) free command shows free physical memory.
b) top command gives free memory and some more details.
c) arch command outputs processor architecture
d) /usr/src/linux-xxx/Documentation/modules.txt gives good info about modules
e) lsmod, insmod, modprobe, modinfo are module related commands. man them for info.
lsmod followed by modinfo module-name is a good combo.
f) /etc/modules.conf has some module related stuff
g) man bootparam gives info about boot parameters.
h) kernel customization can reduce vmlinuz size to less than 1 MB. Running system takes up about 5 MB less with casual reduction during customization and /lib/modules/kernel-xxx goes down from 29 MB to around 12 to 13 MB.
Non GUI RH9 can run in 32 MB RAM quite comfortably.
i) In /etc/inittab set default runlevel to 3 for console linux and 5 for GUI linux.
j) cat /proc/cpuinfo is an interesting command. Try it out.
k) lspci -v (another interesting command: lists pci devices)
l) dmesg | more shows the boot up messages.
m) cat /proc/interrupts shows enabled interrupts. man proc details the information accessible from the /proc pseudo filesystem.
n) ntsysv is the text mode command for controlling services startup/configuration.
o) Read /usr/src/linux-xxx/Documentation/CodingStyle

Minix OR Linux Kernel Lab – Some Thoughts

The following are rather frank thoughts on whether the lab. course should be on Minix or Linux kernel. This comes from a document I had prepared for discussions with other faculty in 2008.

A Ist M.Tech Lab course can be justified from two perspectives:

  • How it gives students the skills and knowledge that helps them in good implementation of research projects and IInd M.Tech projects.
  • How it gives students the skills and knowledge that helps students to get industry jobs.

Minix Lab course

  • Great and perhaps ideal for in-depth O/S teaching at University level
  • Much more elegant O/S as compared to Linux
  • Wonderful platform for O/S research projects (Linux would be perhaps too cumbersome a platform for O/S research. E.g. New techniques for scheduling may be more easily and perhaps more elegantly tried out on Minix.). However O/S research projects are not so common in Indian UGC/AICTE environment (I believe).
  • Very in-depth course. Good students would be able to handle the intensity but average students may not be benefiting much.
  • IInd M.Tech. projects may be on Linux or Sun Solaris and not Minix. E.g. Cell processor projects.
  • Perhaps only few in-depth OS companies may be more appreciative of in-depth Minix kernel exposure as against overview of Linux kernel and Linux kernel device driver exposure.
  • Most companies where students apply for jobs may have preference for Linux Kernel Device driver exposure instead of Minix Kernel exposure
  • Minix course should ideally follow course book. This helps students as they can refer to the course book to strengthen their understanding of class sessions.
  • Intel architecture exposure would be best suited for the course as the course book follows Intel arch.
  • Lab courses are the only courses (barring some minor exceptions) where students get hands-on exposure. A Lab course should focus more on what the student learns to do as against what the student learns to talk about. Minix Lab course seems to be tilted heavily on understanding Minix code as against doing hands-on assignments. Perhaps significantly changing Minix code would take too much time. Existing code changing assignments in Minix seem to be somewhat trivial.
  • Ideally Minix code understanding (and even processor and processor related code understanding) could be done as part of related theory courses (O/S or Architecture). But the theory courses may not be in a position to spare the time.
  • It would be ideal if we have a defined course content for Minix.

Linux Kernel Lab course

  • Will not be so in-depth as Minix
  • Would involve Kernel customization, writing kernel modules and device drivers. Some exposure to Linux Kernel internals but lesser than that of Minix.
  • May be helpful for IInd M.Tech. projects on Linux platform. Students may be able to explore performance tweaking of kernel. They may even be able to use development versions of the kernel (as they may have new features that their project needs).
  • Knowledge of Writing Linux Device drivers may help IInd M.Tech projects involved with devices like OCR scanners, Honeywell sensors etc.
  • Knowledge of Linux Kernel customization may help in better utilization of upcoming Cluster computing lab as the OS will most probably be Linux.
  • At job interviews most companies in Indian environment will perhaps be more impressed with Linux Kernel exposure as that may be more relevant to work they do (e.g. writing drivers). Most Indian companies employing M.Tech. post graduates may not be into intense OS development.

Minix Kernel Internals

This course must have been last taught by me, if I recall correctly, in 2008 in a deemed university in Andhra Pradesh, India. I think I taught this course for two or three batches/years. The class was I. M.Tech. (Comp. Sc.) and class size was typically around 14 to 18 students.

Essentially this was a course designed to give students a feel of kernel internals design and code.

One interesting discussion I had with other faculty was on whether we should have a Minix Kernel Internals course or a Linux Kernel Internals course. The important points related to my view of that discussion are available here.

Prerequisites for the Course

C Programming including debugging skills, User level knowledge of Unix (Unix commands like ls, chmod, mkdir, kill etc.) and theoretical knowledge of modern operating systems like Unix./Linux Kernel Internals. Note that students typically would learn such theory of modern operating systems in a separate theory course done either prior to this course or in parallel to this course.

Course Book

“Operating Systems – Design and Implementation”, Second edition by Tanenbaum and Woodhull, http://minix1.woodhull.com/osdi2/.

A later edition, 3rd edition, is available, http://www.flipkart.com/operating-systems-design-implementation-3rd/p/itmdytczcxvugj3h. But I do not know whether it is appropriate to use that book for this course material. [BTW Instructor resources (would be useful for students too, I guess) is available here on request, http://www.pearsonhighered.com/educator/academic/product/0,3110,0131429388,00.html#resources. This course site of a US university, http://www.cise.ufl.edu/~nemo/cop4600/, seems to be using the 3rd edition book as the main course book. The site has slides which can be downloaded.]

Note: While the course book has some theory of Operating Systems as well, this course focuses only on design and implementation of Minix. A separate theory course on Operating Systems is done by students either prior to this course or in parallel to this course.

Minix website: http://www.minix3.org/

Teaching with Minix Howto (has links to Minix course websites): http://minix1.woodhull.com/teaching/

Chapter Wise Study Notes

Chapter 1 – Introduction

If time permits the whole chapter should be read. Sections 1.2.5 – History of Minix, 1.3 – Operating System Concepts, 1.4 – System Calls are important sections which MUST be read (they are a reading assignment for this course).

Given below are some notes of the important parts of this chapter for this course.

History of MINIX

  • Tanenbaum writes MINIX from scratch using same system interface as UNIX but the implementation being completely different from AT&T’s UNIX thereby avoiding licensing issues and making MINIX suitable for study in edcuational institutions (like universities). MINIX stands for mini-UNIX.
  • Students can dissect a real operating system – MINIX – like biology students dissect frogs.
  • MINIX code is meant to be studied and be readable unlike UNIX where the objective of the design was efficiency.
  • This book’s MINIX version is based on POSIX standard.
  • MINIX is written in ‘C’ programming language.
  • MINIX initial implementation was for the IBM PC; subsequently ported to other machines/architectures like Macintosh and SPARC
  • Running MINIX similar to running UNIX; commands like ls, cat, grep and make as well as the shell are available.
  • Finnish student, Linus Torvalds, wrote a MINIX clone called LINUX to be a “feature-heavy production system” as against an educational tool that MINIX is.

Operating System Concepts

  • System calls are the interface between OS and user programs

Processes

  • A program in execution is a process
  • A process had address space – memory locations which the program can read from and write to
  • Address space is divided into code – executable program, data and stack; (stack is also data but of a different type)
  • Each process has a set of registers including program counter and stack pointer needed to run the program (using the underlying processor and processor instructions).
  • In a time-sharing system OS suspends one process, saves its process state, and starts/re-starts another process; the suspended process is re-started after some time at which time first its process state must be restored; process table entry stores the process state when the process is suspended
  • Command interpreter or shell has to execute programs; as part of program execution and control of that execution it needs a system call to create a process which will execute the program; on the program finishing a system call is needed for the process to terminate

Files

  • Broad category of system calls that deal with the file system
  • system calls are available to create and remove files; to open, read, write and close files
  • hierarchical directory structure: system calls available to create and remove directories; put an existing file in a directory, remove an existing file from a directory; a directory itself can be a file entry in another directory thereby providing for a hierarchical directory structure
  • 9-bit file protection code giving rwx permissions for owner, group and others

Shell

  • Command interpreter is called shell; it is the primary interface between user on terminal giving commands and the operating system
  • On user login a shell is started up for the user; typical prompt is $; user types in command at this command prompt
  • input and output file redirection via < and >

Memory Layout of Process

  • A process has three segments in its address (memory) space – text (or code), data and stack; data segment grows upward and stack segment grows downward (see fig. 1-11)

Monolithic Operating System with User Mode and Kernel Mode

  • Most CPUs have (at least) two modes – kernel mode where all instructions are allowed and user mode where some instructions are prohibited
  • Special trap instruction in the CPU instruction set known as kernel call or supervisor call switches the CPU from user mode to kernel mode
  • Parameters of the kernel call/supervisor call instruction are used to identify which system call should be invoked

OS components

  • Four components of Minix OS – process management, I/O device management, memory management and file management; course book chapters are also on these lines.

Lab work: Installing VMWare on Linux and then installing Minix on VMWare (Instead of VMWare for some years/batches Bochs emulator was also used). One great advantage of using Minix on VMWare for this course was that Minix kernel crash (due to modified kernel code of students typically) only crashed the virtual machine. Bringing up a new virtual machine Minix (with stable kernel) on VMWare was quick and straightforward. This contrasts very positively with the time lost on Minix kernel crash on physical machine and resultant time and effort to bring up Minix (with stable kernel) on the physical machine.

This link provides info. on installing Minix on VMWare and other virtual machine/emulator software, and has some other related support info. too: http://minix1.woodhull.com/hints.html#emul-virt.

Chapter 2 – Processes

Section 2.5 – Overview of Processes in Minix and section 2.6 Implementation of Processes in Minix (pages 93 to 147) are very vital sections of the book. These are the first, and perhaps the most important, sections that delve into Minix kernel source code. These sections have to read and understood in conjunction with the actual source code they refer to.

[The Minix source code listing is provided in the book itself as Appendix A – The Minix Source Code from page 523 to page 903 (380 pages) consisting of 27646 lines of (line numbered) code. Appendix B is an Index to Files (pages 907 and 908) which gives the filenames and starting line number in listing for files in include directory, kernel, memory manager and file system. Appendix C is an Index to Symbols (Pages 911 to 923) giving symbol name and listing line number. These symbols include function names and macros (#define).]

[I discussed these sections (2.5 and 2.6) in class and also walked through appropriate code where required. These were intense sessions and required high level of commitment from students if they wanted to really benefit from the course.]

These sections involve some assembler code. Some, if not all, the detailed pages/sub-sections are listed below:
a) stackframe_s structure: Page 115 Lines 4537 to 4558 (Lines refer to the source code listing included as Appendix A)
b) mpx386.s Page 124
c) Section 2.6.7: Interrupt handling in MINIX, Pages 128 to 137
d) Section 2.6.10: Hardware-Dependent Kernel Support Pages 142 to 145
e) Section 2.6.11: Utilities and the Kernel Library, Pages 145 to 147

The assembler code (if I recall correctly) is Intel 386 code. So there must be some understanding of Intel 386 architecture and instructions. The students would have taken a computer architecture course in the past which would have covered Intel 386 architecture and instructions to some extent, at least.

The wikipedia page, http://en.wikipedia.org/wiki/Intel_80386, seems to give a decent overview of Intel 386.

An Intel 386 programmer’s reference manual is available here: http://intel80386.com/. From this reference these two chapters are important for understanding the assembler code (if I recall correctly) in Minix source code referenced by the course book:

Lab. Assignment: Change process scheduling algorithm – I am afraid I don’t recall the details now – could be changing scheduling from round-robin to lottery scheduling (random).

Assessment: Ideally assessment for this very intense chapter would involve quizzes/viva-voce to examine a student’s understanding of the design and implementation details covered by this chapter. However, I have to be honest and state that very few students of the batch had the time, inclination and/or resolve to get that deep into Minix design & code. Most students chose to focus on doing the lab. assignments where one could do some fiddling with part of the code without having got a full understanding of the design and code covered in this chapter. I could not blame the students much as the time available for this lab. course in terms of both study time and computer lab. time was limited (competition from other courses and other activities that students had to get involved with). Having said this, I must also say that the objective of exposing most students to the complexity of kernel internals of Minix got achieved with intense coverage in class of some of the design & code covered by this chapter. So, if in future, say for a IInd M.Tech. (CS) project, a bright student chose to do an OS component design & implementation project (like a filesystem implementation/port to Minix), the background exposure would have been provided by this course for the student to take up the challenge.

Chapter 3 – Input/Output

In this course we do not focus much on this chapter. However the following sections must be read as they may be useful (are useful, if I recall correctly) for better understanding of later chapters:

  • 3.4.1 Interrupt Handlers in Minix
  • 3.8.3 Overview of the Clock Driver in Minix
  • 3.10 The System Task in Minix

Chapter 4 – Memory Management

This whole chapter is an important part of this course and so the whole chapter should be read. In particular the following sections must be studied in-depth:

  • 4.6.3 Segmentation with Paging: The Intel Pentium
  • 4.7 Overview of Memory Management in Minix (including subsections)
  • 4,8 Implementation of Memory Management in Minix (including subsections)

The following topics were discussed in depth in class – fork system call implementation; Process scheduling, process table, process memory map and Translation. Viva-Voce/Quiz was conducted to test understanding of these topics by the students.

Lab. Assignment 1: Modify memory allocation algorithm from first fit to best fit.

Lab. Assignment 2: Add a new system call in MINIX (in MM). The system call should take in, say, two parameters, and have a return value. The system call’s service may be a very trivial one as the objective is to understand how add a new system call to Minix (and then test it, of course).

Lab. Assignment 3: Add a new system call in MM that gets the memory map for the requested process.

 Chapter 5 – Filesystems

Due to lack of time this chapter was not covered. However, if students have the time and inclination this chapter should be read and understood. [A couple of students who underwent this course in Ist. M.Tech. (CS) took up implementation/port in Minix of a filesystem supported on Linux but not in Minix (2.0). That project involved understanding this chapter and related code very well.]

Linux Kernel Customization – Mini Course

This mini course was taught by me only once in 2008, if I recall correctly, in a deemed university in Andhra Pradesh, India. As it was not a full-fledged course I have chosen to provide details of the mini-course, and suggestions to make it a full-fledged course, as a report.

Towards the end of the Minix Kernel Internals Lab course for Ist M.Tech. (CS), for a period of 6 days this mini-course/sub-course was conducted. The following topics were covered:

  1. Building the Linux Kernel. Students were taken through the steps of building the Fedora 7 Linux kernel. Topics explained included: Need for customized kernels (embedded devices, performance optimization, usage of new kernel features which are available only as kernel patches, bug fixes), boot process, grub, linux kernel executable files, statically linked kernel and dynamically loaded modules, related commands like uname, lsmod, /proc pseudo-filesystem, lspci etc., rpms needed for building kernel, configuring the kernel, installing the newly built kernel.

Students built two to three versions of the Fedora 7 kernel: A standard kernel similar to the Fedora distribution kernel and one or two smaller kernels. Some groups of students were able to reduce the kernel dynamic modules from 441 MB to less than 100 MB. They also were able to marginally reduce the statically linked kernel. As time was short we stopped at students getting a reasonable idea of what kernel customization involves.

  1. Very Simple Hacking of Linux Kernel. Kernel code was modified to include some printk statements. Students rebuilt this kernel and observed the output of their printk statements.
  2. Writing simple Linux Kernel modules. Students wrote one or two small modules and inserted them into the running kernel using insmod. A small kernel module which handles interrupts was also studied and demonstrated.
  3. Kernel patches. Quick introduction to Linux kernel patches, applying a patch and also creating a patch; importance of patches when contributing to Linux kernel community. We did not have time to do hands-on assignments for these topics (kernel patches).

Note: Evaluation of students was done by studying their assignment reports and by a Viva voce.

Linux Kernel Customization slides

Remarks

While this sub-course of 6 days (2 timetable hours per day) did give students a foot-hold in the rather intimidating area of Linux Kernel customization and Linux Kernel Programming, the period was too short to achieve any substantial goals.

I now feel that the minimum goal for such a sub-course would be the following:

• Build a minimal Linux kernel for an embedded device. Perhaps we could test that kernel using a simulator for that embedded device.

• Write a small but functional Linux device driver.

If these two goals are achieved then students will have gained something substantial. It may be of direct help for a possible device driver IInd M.Tech project. Further, students can mention it in their biodata and also talk about it during job interviews.

However, for such a sub-course the minimal period would be 4 weeks (assuming 8 timetable hours per week).

If required the course can also be made a full course by making the tasks mentioned above more complex like writing a full fledged device driver, and adding suitable topics from the resource links given below.

—- end report —

Making the Linux Kernel For Fedora 7 – Instructions and Log

Resource Links

(IBM Developer Works) Hacking the Linux 2.6 kernel, Part 1: Getting ready – http://www.cagdastopcu.com/wp-content/uploads/2010/01/l-kernelhack1-pdf.pdf

(IBM Developer Works) Hacking the Linux 2.6 kernel, Part 2: Making your first hack – http://marcelotoledo.com/wp-content/uploads/2008/04/l-kernelhack2-a4.pdf

Personal Fedora 7 Installation Guide – http://www.mjmwired.net/resources/mjm-fedora-f7.html

http://kernelnewbies.org/http://kernelnewbies.org/KernelBuild

http://www.kernel.org

The Linux Boot Process – http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch07_:_The_Linux_Boot_Process

Modifying the Kernel to Improve Performance – http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch33_:_Modifying_the_Kernel_to_Improve_Performance

http://www.linuxfromscratch.org/

Linux Kernel Programming US university course link – http://www.cs.utexas.edu/users/ygz/378-03S/