Linux

Had an interesting day on Sunday - didn’t go anywhere but stayed in and made headway into a Linux Device Drivers book I had purchased a while ago. It was a good time to read it because I’d just finished Linux Kernel Deveopmment(A programmer’s library) and If I’d not read that, well i doubt I’d have made much sense of this book at it takes a lot of topics and theory for granted. For example memory barriers aren’t even discussed in an example unlike the previously mentioned book - however that being said I did find this topic boring anyway so maybe it wasn’t worth the bordem i went through. I’ll use it eventually but this device driver book is more practical in terms of writing kinds of device drivers.

I did find that the kernel sources have moved on quite a bit since the book was published, some of the function calls have been renamed but not by a great deal - for example in the drivers/char/dsp*.c driver you can see that instead of calling device_create_class(), its just create_class() - Also it made me realise how important the sources are for examples and reference. 

So I’ve finished reading my latest on the Linux Kernel which is good but that certainly doesn’t make me a kernel developer – far from it. I’ve got a good appreciation for the subsystems in the source tree now enough to start hacking it and figuring it all out. My only concern at this point is time. Time is something we all have but its relative (apparently) to the priorities and interests in your life. For example, if you’re interested in running now, well you’ll have lots of time relative to running, less time say to reading or writing about the kernel. So I’m always at odds with what’s more interesting/important/cool in relation to anything else that needs my time. Come to think about it, I guess I’m much like the scheduler in the kernel. Determining what is the best usage if my time. Only the real difference is that my criteria are more numerous to the linux kernel. For example, the scheduler just needs to do that which hasn’t been done enough of yet(run processes that haven’t run as long yet as all the other processes that have ) in comparison to everything else that has done things.

Ok so I;m back at work and that means two things, my day is pretty full up with my day job, which is fine/cool ‘cos I like doing AppV stuff. Just need to re-focus a bit so my work on the kernel has slowed down. That said on the bus last night and this morning. I read up on the VFS abstraction interface provided by the kernel. Mostly learned about the superblock ,inodes and dentries.

Its that period after Christmas and just before new years that everyone has taken off, so it pretty quite in the office. That's actually pretty cool because a) no ones asking me questions and b) its quite and c) I can turn my music way up. I mean at times the lights just go off and I’m sitting in front of my monitor and I have to occasionally do a ninja kick move to re-activate the motion sensors to get the lights to go back on.

I finally started scratching an itch I’ve been having for a while – device drivers - and leaning exactly how the Linux Kernel internals function. Stuff like process creation, memory management, threads etc.

Its taken a while to begin this work mostly because I know its a big-start, it requires a lot of time to invest in reading and figuring stuff out and really what this all boils down to, is that it needs continuity.

By continuity I mean that it requires learning a lot to just get a little knowledge, so you need a lot of time to actually get somewhere. For example, you need to read a bunch of theory around processes and scheduling and kernel data structures not to mention how the hardware interfaces with the processor and the OS etc… So you need to have time to do that, and If I know that I’m just not able to provide that, a little bit here and there will be a lost cause. You need to tie things together and ‘things’ only become things when you’ve invested the required time to know what they are.

I wrote my first kernel model code today. It was in the form of a loadable module which I compiled and loaded into the running kernel. Interesting how easy it was. They really do seem to try and make it as easy as possible. I guess this is in the spirit of having other people do stuff for you because a) they can and b) its easy so you don't have to do it. Veru clever.

I tried to load my module into Fedora and it frankly wasn't impressed. It told me that my module was unsigned and that it 'tainted' the kernel... Mphh! Anyway thats because the kernel in Fedora 25 is compiled such that it only accepts signed code. Fine I guess so short of compiling a new kernel for Fedora 24, I switched to my Debian VM and loaded it module and its was all good.

A quick dmesg revealed the power of my achievement - 2 words - "hello kernel!".

What's particularly gratifying is the usage of the kernel's printk() function from the kernel API which is similar to user-mode printf().

I couple of weeks back I started reading a book about Linux device drivers and while it was interesting I slowly lost interest somewhere between block drivers and graphics drivers, piqued interest around the USB subsystem drivers and then well put the book down. The problem is just that. Unless you have a problem to solve, it just doesn't do enough for you. So, I having thought about it I'd like to write a USB device driver. The problem now is for what?

Maybe its time to 'make' a device. Oh yes. That's  a suitable problem to overcome. Then it will be to plug that device into a computer and have it commnuicate with it - that's right a device driver!

Anyway today, I downloaded the latest kernel source code, compiled a default configuration for x64 and had a quick browse through the source - time to put my bib and start feasting.