Re: dnspacket.ml

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

[am in Imperial in meetings all day, so excuse delayed replies]

On 27 Jul 2011, at 14:51, Éireann Leverett wrote:

> 
> I'm guessing I should be using the interfaces instead of linking all files 
> together (perhaps this is what you meant). So for DNS I can see eight 
> currently defined:
> 
> server
> hashcons
> dnstrie
> dnsserver
> dnsrr
> dnsquery
> dnsloader
> dnslexer

Right… these are packed together into the Dns module via the 'dns.mlpack' file, 
which indicates that the modules within should be packed under the Dns 
namespace (so Dns.Dnstrie for example).

However, to start with, you could also add your resolver code into client.ml, 
add Client to the dns.mlpack file, and not have to prepend everything with Dns. 
 See server.ml for an example of this.

> 
> Which is now starting to make a lot more sense. However, can anyone tell me 
> what .mly files are for?

.mly files are ocamlyacc files for defining grammars. The ocamlyacc tool is 
similar to the C yacc, except it outputs OCaml parser tables instead of C ones.

This is used in DNS to parse zone files, and the build system automatically 
generates OCaml modules by calling ocamlyacc on the .mly file.


> 
> Also, does mirage generally use the ocamlc or ocamlopt compilation? The book 
> establishes the difference as primarily easilydebuggable&portable 
> -v-performance enhanced&native code. Is there any more to that story?
> 

It actually generates both. The programmer shouldn't be able to observe the 
difference from within the OCaml program (it only makes a difference for speed, 
in practise). Some backends use the byte code files to do further code 
generation (e.g. to Javascript), but the Xen backend exclusively uses the 
ocamlopt native code backend.

-anil