Notes from the BIND 10 call




  • Roll call
  • AP from last week:
    • Shane to try to make a graph of timeline
    • Shane to give commit access to Francis
    • Jeremy to make coverage tests automatic
    • Jeremy to try man page generation from source code
  • Status of coverage tests
  • CeBIT 2010
  • Developers
  • Status check
    • DNS Message API
    • msgq
    • Configuration
    • Command & Control
    • Statistics
    • BoB
  • Data Source
  • AOB

Jelte noted that he didn't have time to see the agenda, so Shane promises to send it out at least 24 hours in advance from now on.

Action Points

See above.

  1. In progress
  2. Done
  3. Not yet, although some manual URLs have posted to the Jabber room
  4. No... playing with tools... not really made for doing user documentation. Maybe wasting time, and should just write man pages.

Shane: anybody know about man pages from source code generation?

Jelte: no, not for user stuff, but we can talk about it tomorrow in the Jabber room

Coverage Tests

Jeremy: parking lot has configure option that can build code with coverage test capability, run "make test" give HTML report. I saw Jinmei did that for his code that he is working on. Also did the same thing for some of the Python code, although not in a configure script yet.

Jeremy: been uploading some of the results to server web pages, code has weird function names

Jinmei: tool to mark functions, so we can write a tool as a filter if we need to

Michael: what do function names look like?

Jelte: surrounds function names with what looks like random letters

Michael: yeah, type mangling then

Shane: is there like lcov++ or something like that?

Jeremy: lcov is for C++... but maybe there is an option for this and we're using it wrong

Jeremy: for automating this, maybe we can use Subversion hooks

Shane: Subversion hooks sound sexy...

Jelte: if it doesn't take too much time! I think daily would be enough for this. So it doesn't matter for me if it runs automatically.

Shane: hooks should be easy, and as long as there is locking to avoid running lots at once it would be cool

Jeremy: okay

Jeremy: a few things I misunderstood in the code coverage output. Will be asking mailing list to better explain.

Shane: you mean code coverage 100% and function coverage 50%? (Discussed in Jabber)

Jeremy: exactly

Jeremy: other than that... code coverage seems very useful. I've been seeing lots of commits based on this.

AP Jeremy will be writing a blog article about the coverage test

Jelte: I made sure that coverage was 100% for the parts I wanted reviewed.

Jinmei: I did the same thing.

Michael: I'm so proud of you guys!

CeBIT 2010

Shane: Carsten Strotmann suggested a table at CeBIT, and helped us request one, and BIND 10 was approved! This is for the BIND 10 project, not for ISC. We'll be discussing this in more detail around the end of January/beginning of February, and Carsten will probably join a BIND 10 weekly call or two for this.


Shane: Evan, Shawn, and David may have resources for BIND 10 soon. Still talking with them about what they will work on.

Evan says he will be more available after 9.7 is finished.

Status Check

DNS Message API

Jinmei: completed latest branch of Message API which includes RR types, classes, TTLs. Going for review - ticket #21. Implementation is pretty trivial I think. I believe it is relatively easy to review.

Jinmei: thinking of moving on to the rest of the API, as well as spending some time on the data source API.

Jelte will review ticket #21.


Michael: no review ticket yet [ update - ticket #22 and #23, to be reviewed by Likun & Feng ]


Jelte: put up ticket for review of small part (Element class, which is the data files) - also used by stuff which uses the msgq. But no time spent on general configuration again (busy with data source).

Michael will review ticket #20.

Command & Control

Likun: plan to create a new branch based on Jelte's changes, maybe next week commit to tree

Jelte: if I made any changes to bigtool that you disagree with, feel free to tell me

Likun: only change was going through command & control rather than sending direct. so replace old bigtool with command & control


Fujiwara-san: read Jeremy's ideas, considering what we need to define, will send my ideas tomorrow.

Kambe-san: coding prototype of SNMP agent. Have not yet committed to experimental repository but I think I will within a few working days.


Shane: fixed signal handler

[ Some discussion about SO_REUSEADDR option in the msgq - call setsockopt() before bind()! ]

Data Source

Jelte: nice talk on Tuesday, I sent around on list, Michael did too. Promised that I would send out an updated proposal, but not finished yet.

Shane: where are we at, as of 2 days later...

Michael: hoping we can get to coding soon! Is this going to be SQLite, in-memory, or what?

Shane: simplest would be a vector of structures with a for loop around it

Michael: just to flush out the API. I think the first one should be SQL.

Shane: eventually we'll need a generic SQL version... but maybe not...

Michael: generic SQL back-end is hard

Michael: 3 goals in data source API:

  1. Anybody can write these, even if just fixed data from a script!
  2. Some semblence of sanity in the way data is associated together (signatures need to be part of data)
  3. Code reuse possible as much as possible

Michael: So we have to have some intelligence at the low level. So maybe callback functions.

Jelte: I was looking into what we need to have a "catch-all" data source, where you don't know whether we have the zone in advance. So a "do you have this zone" function, or "what would be the zone for this name?". Maybe we need an init() function that you then use on a data source.

Shane: is this something that happens every search, or...?

Jelte: it could be, or one that you use for a class of search functions later.

Michael: we need something like "what is the best zone you can give me for this query?"

Shane: we agree that we need a data source where you don't know what zones it serves?

Michael & Jelte: yes

Michael: I understand updating signatures need to be updated with RRSETs.

Shane: I was thinking of the query case as more worrying.

Michael: not a problem as long as you know about signatures...

Shane: worried about putting NSEC & NSEC3 processing in the lower level

Michael: signatures need to be part of data. Flag that says "no DNSSEC supported".

Shane: more worried about how we can get consistent data out

Michael: no reason to make it complicated for how to use this API

Shane: if API consumer has no way to say "these queries are related", API provider has no way to know to make them consistent

Michael: find() is implemented on top of findRRset()... so if we need transactions, they would be in the low level

Jelte: I just didn't call find() I called it getData or something.

Michael: may as well call it find()

Michael: update queue serial if necessary...

Michael: but not now!

Shane: outstanding issues?

Michael: who's doing what, and so on, so we have something at end of January

Shane: sure... re-rev of header file would be cool.

Jelte: already doing that in special branch of parking lot so it's staying at a "it still works" level

Michael: would also like RDataSet to contain signatures as well

Jinmei: can simply go with current parking lot API. Don't expect interface will be so changed.

Michael: addition of one other thing...

Jinmei: right, we can easily adapt it later

Michael: so for now we can assume we are not using DNSSEC

Jinmei: regarding time frame... depends on the goal of the next face-to-face version. Actually want semi-working or completed.

Michael: never completed! Semi-working base idea by end of January is the goal. Time to code together?

Shane: most of the week is coding I hope!

AP Shane to make agenda for face-to-face meeting


Larissa: sent mail to staff list about arriving/leaving for face-to-face will have Kat set up hotel arrangements

Michael: which hotel?

Larissa: same as for all hands

Last modified 9 years ago Last modified on Jan 15, 2010, 8:14:10 PM