[ossig] FOSS.in Conference Day 3 + Overall Impressions

[Ditesh Kumar]

(for full linkage, please visit:
http://ditesh.gathani.org/blog/2007/12/17/fossin-day-3-the-last-day-reports-overall-impressions/)


We were slightly late for the first talk as I had some trouble checking
out of the hotel. The first talk was an “Introduction into practical
real-time programming in userspace in Linux” by Lennart Poettering from
RedHat. Fairly informative talk. I didn’t get to jot down many notes so
… :)



--- Contributing to the Basic Runtime

Ulrich Drepper spoke on how to contribute to the basic runtime, the
basic runtime here being the system API. The system API consists of many
interfaces including the kernel API, processor specific code, various
implementations of standards and so on. He mentioned that the C library
has lots of processor specific code (which too makes up part of the
basic runtime).

An important bit in the runtime is ensuring version stability. The basic
runtime has not broken ABI compatibility for the last 12 years and as
such, it must work with all/many different kernels, must be backwards
compatible and maintain ABI compatibility.

Ulrich then listed a set of important standards:

      * ISO C
      * ISO C++
      * POSIX
      * Unix
      * IETF RFC’s
      * OpenMP

(all of these standards add up to several thousand pages)

The runtime can be broken down to libgcc (which GCC provides; GCC
generates calls to routines in this library automatically, whenever it
needs to perform some operation that is too complicated to emit inline
code for), C and math libraries (which Ulrich maintains), a C++ library,
OpenMP and a thread library.

Ulrich’s talk then went on to describe areas in which contributions can
be made. This seems to be a good place for potential FOSS contributors
(with some background in C) to contribute meaningfully.

Personal thoughts: Good, balanced talk.


--- talloc: The Power of C

Rusty Russell spoke about talloc. He started off by speaking about what
he considers to be a myth of interface design: that interfaces should be
easy to use. He felt that interface design should be structured such
that interfaces should be hard to misuse as this is slightly more
important then making them easy to use. He made a further observation
that most of coding is about damage control - ie, ensuring that errors
are correctly generated and exceptions are caught.

With that, he spoke about jitterbug, a web based bug tracking system
written in C by Andrew Tridgell. He was perplexed at first when he saw
that jitterbug did not free() any of the memory but that was because the
operating system itself was the garbage collector (when the HTTP request
died, all resources would be freed).

Rusty then jumped into some coded, gave examples of key/value allocators
and illustrated the problems of memory management in such systems. There
were several technological solutions for key/value allocators. First is
simply not to use such systems. Second is to use garbage collectors
(which don’t really work too well in critical applications, malloc
overrides and memory pools.

Enter talloc. Talloc is a hierarchical allocator whereas every pointer
returned from talloc is a pool. This means that free()-ing a parent node
automatically free()’s all child nodes. voila, much of the memory
management problems disappear. There are some program’s using talloc
including talloc itself, Samba 4, NFsim and Xen Store Daemon.
Apparently, Tridge spoke to Linus about using talloc in the kernel but
given Tridge’s reverse-engineering of BitKeeper in 2005, Linus wasn’t
too happy and talloc never made itself into the kernel.

Rusty went through some code showing how talloc can be used. He
mentioned some known benefits of talloc, including it being a drop in
replacement for malloc() and free() (at the cost of a small performance
hit), it gives explicit documentation on the lifetimes of objects, and
it helps find memory leaks. He then showed the dot graphs for SAMBA v4
allocators.

On to Q&A. First question was about how talloc allocates in pools. Rusty
clarified that talloc doesn’t allocate in pools (thus there being some
misunderstanding on allocation strategies) :DOn scaling talloc, Rusty
says that talloc scales very well, mostly on the order by O(1) although
allocation itself is O(n). Another person asked whether it was possible
to free() the parent node but not the child node. That question made
absolutely no sense to me and apparently, it did not make sense to Rusty
either. However, a child node can be moved to a different parent using
talloc_steal() and the original parent node then be freed. As to whether
talloc() imposes performance overhead in a non hierarchical use, the
answer was not really because using talloc would not be any different
from using a manual malloc(). A good question was on thread safety.
Apparently, talloc is not thread safe and possibly never would be given
that threads are Evil(tm)!

With that time mostly ran out and the talk was over.

Personal thoughts: Fantastic talk!


--- Overall Impressions

I had to go catch a plane at this point so I couldnt write down my
impressions from other remaining talks. FOSS.in is a great conference.
One bit which I did not blog about was the Mozilla party. I had some
nice conversations with the Sun OpenOffice hackers (who strongly
admitted to their Open Source and Open Standards support), met up with
Danese Cooper, had a chat with GopalV (APC hacker) , Srivatsan (freenet
hacker) and a whole bunch of other folk. Particularly cool was FOSS.in
team making sure we got home safely from the party (thanks Shres,
Shilpa, Tejas, Kishore).

The talks were great, lunch was available quickly and was decent, the
organizers were freaking organized and there was hardly a hiccup visible
to attendees. Well worth the visit!

-- 
  May your signals all trap                     Ditesh Kumar
May your references be bounded                ditesh at gathani.org
      All memory aligned                http://ditesh.gathani.org/blog
    Floats to ints rounded              http://www.openmalaysiablog.com