Compsing Bibtex entries for use in Latex can be a pain at the best of times. Deciding which entry type to use, entering all the authors, page numbers, journal/conference name etc etc.

I was messing about in nautilus the other day and accidentally double clicked on one of my bibtex files. To my surprise a nice GUI application called KBibteX opened with my bibtex entries from the file all organised.

After a little more playing around with it I found that it is extremely useful for adding new entries. A nice GUI lets you enter all the information into text fields and view the output source at all times. Then when an entry has been entered you can click on it in the overview and it will show you how Latex will display the output.

I would definitely recommend KBibteX to anyone that has to work with Bibtex on a regular basis it is a real nice time saver.

Of course a lot of the time it is possible to find entries for papers etc already composed from well known sources such as citeseer. For computing references I would highly recommend The Collection Of Computer Science Bibliographies. The site is not always the most reliable but the number of bibtex entries it contains is phenomenal and regularly updated with the latest papers.

I have been doing some more kernel module coding and have been using the linked list implementation provided by list.h quite a bit recently as I have known in advance that the lists would only ever have a small amount of entries so looping through the list would not prove to be too much of a performance penalty.

For my latest problem however I have a list that could grow a bit larger in size so I made the decision to use a hash table instead of a linked list. I searched through the kernel source naively hoping there would be a neat generic hash table implementation included.. Alas there is not.

After a bit of searching I stumbled across uthash. This is a nice hash table implementation allowing you to basically put any struct into a hash table based on using one of the fields in the struct as the id. The included macro’s allow a string or an int to be used for the id as well which is quite useful.

So far it seems quite simple to use. All the functions are included in one header file wrapped us as macro’s so it is nice and easy to integrate with any project and it doesn’t rely on much to be included externally. In my case all the functions it does need are provided by the kernel so it was very simple to integrate. I will definitely be using this again in other projects in the future.

I am currently implementing the timeout functionality for the NP++ kernel module. Each physical mapping has a function pointer defined in its descriptive struct (struct np_sw) as described here.

Until now this hasn’t actually been implemented but I wanted to create a kernel thread that simply sleeps for 500 milliseconds, then awakes and looks through all the physical mappings available on the system and calls their timeout function.

This is a fairly simple process but in order to achieve it we need to include a couple of new headers :

#include <linux/kthread.h>
#include <linux/delay.h>
The first of these is for the thread related functions needed and the second is to allow us to sleep the thread.

Now we have those included we need to declare a function that will be called when we start the thread as follows :

int timeout_thread(void *data)
Any kernel thread function needs ro return an int and take a void pointer as the only argument to conform with the function pointer defined the kthread_create() function in kthread.h which the kthread_run() macro is a wrapper for.

Now we need to actually create the thread. I have done this in the modules init_module() function as follows:

kthread_run(timeout_thread, NULL, "NP++ Timeout Thread");
Now this is all done we simply need to put some implementation into the timeout_thread() function to perform the sleep as follows:

while(1)
{
set_current_state(TASK_RUNNING);
//Some Code Here
set_current_state(TASK_INTERRUPTIBLE);
msleep(500);
}
This sets the state of the thread to TASK_RUNNING to tell the kernel that the thread is working. The code to call the mappings individual timeout functions will go here. Then we set the state to TASK_INTERRUPTIBLE to tell the kernel we aren’t doing anything at which point we call the msleep() function to sleep the thread for 500 milliseconds.

Compile the module and you have a nice thread that will run roughly every 500 milliseconds. If you need a longer delay that can be measured in seconds the delay.h header also defines the following function that takes the number of seconds as the only argument:

void ssleep(unsigned int seconds);

Whilst progressing some code I have been writing I was recently introduced to Linux’s XFRM (transform) framework. I had not heard of this before but it can be a very useful tool for manipulating packets.

The one big downside to XFRM is there is virtually no documentation on it yet. This can make working with it quite tricky. I am documenting what I find out from using it here in the hope that others will find it useful.

The basic idea behind XFRM is that it allows you to select a packet based on a number of factors. These are all defined in /usr/include/linux/xfrm.h in a struct named xfrm_selector as defined below :

struct xfrm_selector
{
xfrm_address_t daddr;
xfrm_address_t saddr;
__be16 dport;
__be16 dport_mask;
__be16 sport;
__be16 sport_mask;
__u16 family;
__u8 prefixlen_d;
__u8 prefixlen_s;
__u8 proto;
int ifindex;
uid_t user;
};
Creating a struct of this type and setting the fields such as the source/destination addresses, ports, address masks etc, allows a packet to be selected, based on this criteria, to allow it to be transformed. By passing this information into the kernel using a nlmsghdr struct and the addattr_l() function along with a template (struct xfmr_user_tmpl) describing what action to take on the packet we can alter certain packets however we wish.

This is proving very useful to me in some of my current work and I will continue to post anything I think might be useful to others working in the same area on this blog.