The DF Lab

My senior design project for university has involved a lot of working in the Linux kernel. I’ve found that my primary difficulty with kernel work has been figuring out how the mass of code that already exists works and interacts with each other. It’s mostly very well thought out, but some things take a little time to wrap your head around. One such thing is the kernel’s unified implementation of linked lists.

It’s actually rather ingenious if you think about it, and there are plenty of references that give great explanations of how it all works, so I won’t do that here. The short version is that the list actually acts like an element within another data structure, which allows it to work for all types, rather than having to create new structures and functions for every structure to act like a list. What I recently found myself trying to do was create a queue (first-in-first-out) data structure using the linked lists provided. I decided to go about this after getting a little advice from a couple of fellas over at Stack Overflow. I haven’t fleshed it all out yet, but came to an important realization on how things work. It’s not really all that hard, but it was important enough for me to want to document: because it is a circular, doubly-linked structure, adding an item to the front and back of the list look very similar. In fact, they’re pretty much the same operation, except for where the external head and tail pointers point to. They’re so similar that I spent a bunch of time confused on how it all worked. I suppose that’s my fault for delving in and examining the overly-short elegant code.

The result of this is that their list_add_tail() function (which is commented to be useful for queues) is, in fact, useful for queues. It adds an element linked after the “last” element and before the “first,” given the head of the list. “Last” and “first” are in quotes here because it’s a circular list, so there technically aren’t a first and last, but there are. Anyway, what I still don’t quite understand is how the list_add() function is useful for stacks (also in the comments). Though I’m getting myself slightly confused just thinking about it further, so I’ll end the tirade here.

I guess if there’s one thing I can pass on here, it’s that if there’s comments documenting a series of functions (which the kernel’s include/linux/list.h file does), listen to the comments. I suppose this was a learning experience for me in the end, but I could have saved a bunch of time by just trusting what they said the functions do. On the flip side, if you’re curious, don’t trust them, and want to be sure about what the code is doing, you are always free to dive right in! I’m just convinced that the kernel developers are a lot smarter than I am, at least at this point in my career.

Related Links

• Linux Kernel Linked List Explained
• Another Kernel Linked List Explanation
• Stack Overflow question about kernel queues
• list.h on Linux Cross Reference

linux kernel, linux

A couple of months ago, I spent a lot of time working on a solution for handling all my music and its various uses. Namely, I wanted to keep separate track of:

• All my music (even the music I don’t listen to, so I don’t have to get rid of it)
• The music I listen to on my computer
• The music I have on my limited-space iPod

In addition, I wanted to make sure there was as little wasted disk space as possible, so I used hard links and had all the files in separate directories.

You’d think there would be a relatively simple solution, and I’d hope so too, but I came up with this really convoluted system that involved synchronizing three directories with two scripts whenever music had to be added or removed. What it results in is that I never add music anymore. And somewhere along the line, my “music on my computer” folder got messed up, so I’m back to square-one with that one. Hundreds of songs I filtered out back in the mix.

I wonder if some of my problems would be solved if I used a GUI music player, but I’m not so sure. My current setup uses MPD, which runs nice and light. Anyway, I’m out of mental energy, and am hoping someone else might have a better idea. Does anyone have any good ideas how to maintain my music? Or perhaps a better ideal to work under? Until then, I’ll just suffer under a horrible manual version where I just delete and add things at will to everything and hope I don’t miss things.

linux linux, music

I just received an email from Silence is Defeat about a domain relocation, from .org to .com. It appears their .org now redirects to an eBay auction, auctioning off the domain name itself.

The email I received was as follows:

Hello <username>,

You’re receiving this email because you have the account ‘<username>’ on the SilenceIsDefeat public access unix system.

Silenceisdefeat now runs at this address:

* silenceisdefeat.com

Please note that the old address no longer works, and use the new address for mail, web, and shell access.

You can greatly assist this change by blogging about the new address, replacing any old links to SD with the new address, and even putting up a new link.

As always, you can get in touch with other silenceisdefeat users and administrators in #sd on irc.oftc.net.

Thanks!
The SD team

I thought I’d take this opportunity to spread the word about the change, as well as give a plug to silenceisdefeat. They provide a great service that has come through in a clinch for me on more than one occasion when I’ve needed a public shell to work from (that didn’t suck). My primary shell for university uses SunOS and has some weird quirks, so it’s nice to have an alternative.

Short version: silenceisdefeat.org is now silenceisdefeat.com, and they’re still awesome!

miscellaneous