BIND 10 #2281: use new in-memory data source in the static data source

BIND 10 Development do-not-reply at isc.org
Wed Feb 13 06:06:51 UTC 2013


#2281: use new in-memory data source in the static data source
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  task          |  vorner
            Priority:  high          |                       Status:
           Component:  data source   |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130219
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  4             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by muks):

 * owner:  muks => vorner


Comment:

 Replying to [comment:15 vorner]:
 > I wonder, is it possible the in-memory is directly linked into the
 > data source library itself? Then the symbols would be available.
 >
 > I just fear if it can happen the data source can't be loaded because
 > the in-memory is not available under some circumstances.

 `libb10-datasrc` does link to the new in-memory datasource library. But
 this forms a part of the program that links to `libb10-datasrc`. I'm not
 sure how missing symbols inside the static DS's `.so` get resolved to
 the ones in the main process without `-rdynamic`.

 This is why I don't know how it's happening.

 > That seems like a reason. Can you add a note to the test saying it
 > uses the static data source as an abuse, because in-memory doesn't
 > exist and that the static contains the in-memory one?

 Added. :)

 > Thanks. I wasn't worried about the performance that much (again, these
 > are tests, who cares). But it could be very surprising if someone
 > added another test where it returned the wrong partial match. It could
 > take long time to discover that. But this version looks good.

 Nod. :)

-- 
Ticket URL: <http://bind10.isc.org/ticket/2281#comment:16>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development


More information about the bind10-tickets mailing list