Nervous and excited, we clicked the Submit button at 9:05PM on Sunday. Our code is being reviewed by judges of the ONF driver competition as I write this!!!
Through the day we wrote up documentation, cleaned up code, debugged One Last Bug (more on that later), wrote test plan results, and put together miscellaneous submission documentation.
And we celebrated! Thanks entirely to Rupa, The Awesomest, who secretly planned the celebration for months, we learnt later. Champagne, cake, photo shoot.. I drift..
More on One Last Bug:
Our target was to pull together the submission folder at 4PM, do final reviews, one last test run of the SDN controller and submit at 5. All went well. Until the final test run. There was that One Last Bug, staring right at us. The test was running fine all the way till the very final step of cleanup and then failing on a mutex lock. Horrors - a synchronization issue!! Panic. Adrenaline.
It took 2 of us 3 hours to exterminate that one. A mutex lock was kicking in *after* that mutex was cleared and ofcourse failing on invalid argument. Ofcourse! But hours to the submission deadline, such things are not that obvious at all.
One Last Bug, we got you too!
Back to the title of this post. 200. We couldn't have planned this!
Showing posts with label SDN. Show all posts
Showing posts with label SDN. Show all posts
Sneak Peek - T minus 2
Friday came and went and we got so buried into the submission work that this post almost didn't happen until Ramya - the rockstar coder of our team - made a mention.
So where are we?
The first hello packet is now received by the controller and a hello reply sent out. It's alive!!!!
Some interesting challenges we have been working on:
1. lots of zero sized packets received on sockets - what is the source? are these tcp control packets and if so, why are they punted up? often, read_len is zero even with valid message in the buffer.
2. a change in version of library make the .so suddenly unusable by the application. Why? This is the suspicious diff:
edeedhu@ubuntu:~/edeedhu-git/CC-ONF-driver$ git diff Makefile
diff --git a/Makefile b/Makefile
index fbd20f4..432766f 100644
--- a/Makefile
+++ b/Makefile
@@ -3,7 +3,7 @@ CC := gcc
LDFLAGS := -shared
LIBS := $(shell pkg-config --libs glib-2.0)
RM := rm -f
-MAJOR_VERSION := 0
+MAJOR_VERSION := 1
MINOR_VERSION := 0
3. what is a good method to manually do a static analysis for synchronization? Here's what I came up with - xml style markeup to follow different codepaths and track locking/unlocking of mutexes. How would you have done it?
Now on to some gdb work.
So where are we?
The first hello packet is now received by the controller and a hello reply sent out. It's alive!!!!
Some interesting challenges we have been working on:
1. lots of zero sized packets received on sockets - what is the source? are these tcp control packets and if so, why are they punted up? often, read_len is zero even with valid message in the buffer.
2. a change in version of library make the .so suddenly unusable by the application. Why? This is the suspicious diff:
edeedhu@ubuntu:~/edeedhu-git/CC-ONF-driver$ git diff Makefile
diff --git a/Makefile b/Makefile
index fbd20f4..432766f 100644
--- a/Makefile
+++ b/Makefile
@@ -3,7 +3,7 @@ CC := gcc
LDFLAGS := -shared
LIBS := $(shell pkg-config --libs glib-2.0)
RM := rm -f
-MAJOR_VERSION := 0
+MAJOR_VERSION := 1
MINOR_VERSION := 0
3. what is a good method to manually do a static analysis for synchronization? Here's what I came up with - xml style markeup to follow different codepaths and track locking/unlocking of mutexes. How would you have done it?
Now on to some gdb work.
Sneak Peek - T minus 3
Debugging debugging debugging. What would we do without printfs and gdb..
Our discussions today ranged across locks, pollin events on sockets, swig bindings, mininet, and hash tables, with 2-3 simultaneous topic threads at any given time in the day. And at 7:51 PM, the night shift has just only begun. :)
Our discussions today ranged across locks, pollin events on sockets, swig bindings, mininet, and hash tables, with 2-3 simultaneous topic threads at any given time in the day. And at 7:51 PM, the night shift has just only begun. :)
Sneak Peek - T minus 4
A highly talented team at CodeChix has been working undercover (well, almost and not anymore) on a mission - create a software library for SDN. The goal? A working submission for ONF's Open Flow Driver Competition.
We are officially 4 days away from submission! With 7000 lines of code and testing ongoing at a feverish pace, the progress so far:
1. One end to end channel UP - check!
2. One message plumbed through from source to destination - check!
We are in the most exciting phase of all - the 'make it work' one. ;) More updates tomorrow!
A sneak-peek at our github private repo:
We are officially 4 days away from submission! With 7000 lines of code and testing ongoing at a feverish pace, the progress so far:
1. One end to end channel UP - check!
2. One message plumbed through from source to destination - check!
We are in the most exciting phase of all - the 'make it work' one. ;) More updates tomorrow!
A sneak-peek at our github private repo:
Subscribe to:
Posts (Atom)