the kernel hitch

as much as there are fans for the linux kernel, there are more than that many things that
one should know while reading kernel for the first time.
(I must say the word "reading" is a very bad choice but had to be used for want
of better words)
Though it is really early for me to try and write something about this, I'll try to string my
initial impressions in words thus -
Very broadly speaking,
1) It was initially a academic project by a single guy.
2) You will be brainwashed about its design being "simple"
3) You will understand that what you know of C is simply peanuts.




More elaborately,
I) For most kernel code all your standard libraries that you have been using throughout
like you had been breathing air freely, *will not* be available. You may try and make
them available for your local piece of kernel code and get lost in the mire of complications
that arise. A list of most commonly used kernel API is documented.
II) Speaking of simple designs, suppose you were to completeky know what is involved in
opening an editor for a nfs mounted file and go ahead and edit it .... your simple mind will
boggle. If yours is not a simple mind, it will shiver slightly at the least. It is something like this -
1) The editor will invoke a local syscall such as read on the file based on its local inode
2) In this particular case the inode happens to be an rnode (non - local inode) and therefore
when the sys-call looks into the filesystem info stored therein and realises that it is nfs ...
transfers the call to the corresponding nfs-open/read/write/....
3) Then nfs-client code for open/read/write/... first checks the attributes of the file from
the local directory cache of the server state (if it the cache is still valid) or generates an RPC
call to get the file attributes by giving a "file handle" as a parameter.
4) From which it decides whether it can go about asking for whatever the upper layer wanted it
to do.
5) IF yes, it generates another RPC call for the actual operation .
6) The server (which has been whistling in the meanwhile) gets the request and checks to see
if the user has the permissions to do what it is being requested (i.e. to see if the story changed
in between the RPC calls ... ... ) .
7) If yes, generates a buffer with what is required and prepares an RPC message and sends it
across .... (If no ...it sends an error saying the client's brain is muddled with prejudices)
8) The client (which might be whistling ... (sleeping .. i mean ) is woken up and then it gives
back the results/error from RPC message to the upper layer .
all this not side tracking to the gory details structures and various points of failure and recovery.
The design may be a simple for the purpose but it is in no way, a "simple" design.
(Kernel guy: Hey !! I was just following the RFC ... ok ?)

III) You know what, C is almost OO. I mean .. u can write code in C in such a way that
you get almost all (inheritance ...etc included) objected oriented results. For example
the various file systems that exist in a typical linux kernel implement common functions
and structures already mentioned in the vfs (virtual file system) code ... and almost all
things in vfs code are like abstract base class in C++. I'll say no more here as it is fun to
look at the code and see things for yourself.

Anyway .. looking forward to some exciting kernel hacking.