== No it isn't! It just squirts blocks in and out of the hard drive using kernel/hd.c! Call that a file system? ==

Okay, I guess you're right.  All we have so far is a scheme for peppering bits of the disk with disk
Let's delve a little further.

So far we have:

||||kernel/hd.c||Scary interrupt handling and queueing things||
||||fs/block_dev.c||Cosy things to shift bytes into and out of the hard drive using hd.c (for instance,block_write())||

I guess we need to do the grep thing again.  WTF uses block_write()?  Whatever it is, it's a good candidate for the file system.

== I'm waiting... ==

And I'm grepping.

Well, my grep threw up fs/read_write.c.

This is getting good!

fs/read_write.c contains the code for sys_read(), sys_write(), and sys_lseek().

== Woah!  This suddenly looks waay too simple!  There's no way that this would work in the real world.  What about floppies?  SCSI? ==

Here we hit some more of the limitations of Linux 0.01.  It was designed to boot from some boot device using BIOS calls and then all it had to know about was the particular species of hard drive that Linus Torvalds had access to.  Although there is provision for other devices, this obviously wasn't as important as getting a bootable kernel that could read and write files and, as a consequence, provide the system with the ability to load and execute programs.

== This isn't going to teach me how to produce my own file system. ==

Damn right!  This is a micky mouse filesystem, but it works.   People could download the source, reproduce the bugs, fix them (but mostly not), and start emailing the author with the bugfixes (but mostly complaints).

The point here is that the author was after a single effect: to provide him with an environment in which he (and others) could test their kernel programming skills against the huge amount of free UNIX/POSIX-based software that was available during the early nineties.  He was massively successful, we know now.

Back to KernelHacking.