So I've been back in Canada for slightly longer than a week and I'm working full time for Visible Assets until the end of September.
I've decided to postpone my flight back to Hamburg until the end of September so that I can spend a bit more time with friends and also get a bit more done for work.
Right now, I'm sitting in Montréal at Erin's place. It's been nice to be back - actually, I think I'm suffering less culture shock in Montréal than I would be in Toronto. To tell you the truth, I think mon fronçais went straight down the garbage chute since October, as if German had totally displaced it in my brain. I really think that I'm going to have to work hard at it when I get back to Canada full time, and it would be nice to work towards some sort of bilingual certification or something.
A good friend of mine from the undergrad days, Ed Cote, is in Montréal at a conference presenting some of the work he's done at Queen's, in his master's program. He just finished this past semester (I'm jealous!). Today we're going to be meeting up for a 'cinque à sept', which basically means to have a few drinks at the end of the work day. I'm looking forward to getting out on a patio and having a couple of cold ones, especially in this heat!
For the next month and a half I will be porting much of the code that I've done in user space to kernel space - well, as much as possible, i suppose. Things that I won't be able to convert to kernel space are services and so on.
Particularly, one thing that I'm working on at the moment is a virtual block device that represents tracked / timed connections to the blaster device. What's particularly strange about this, is that I'm hijacking a serial device from within kernel space, albeit with a removeable module.
So far, it's going pretty well and I even have my module initializing the uart, but I've encountered a couple of segfaults. Luckily, I'm testing all of this using Qemu ;-)
Update (2007-08-09): I've managed to fix all segfault issues with serial hijacking by exporting a function init_tty_dev, which is just a wrapper for init_dev, in drivers/char/tty_io.c . Now the uart_driver->tty_driver->tty_struct array will contain a non-NULL pointer to a tty_struct which init_dev initializes. This must always be released with release_tty_dev( struct tty_struct * tty, int idx ) when the module unloads in order to return the refcount.
